Subkeys

Modern OpenPGP keys are actually a set of keys. This set contains a primary key and (usually) several subkeys. When generating a new key with sq key generate, sq will create three subkeys along with the primary key: each of the subkeys are marked for their respective use (authentication, signing, encryption).

This set of subkeys is identified by its primary key, so adding and removing them doesn't change the fingerprint. Certifications are made for the primary key as well - so modifying the subkeys doesn't affect them.

Subkeys are just like ordinary keys. What makes a key a subkey, is the existence of a subkey binding signature, which marks a specific key as subkey to a primary key.

Subkeys are different from primary keys, as they do not contain User IDs.

Primary keys and subkeys can be thought of as a tiny local personal PKIs, where the primary key is the CA, certifying the subkeys.

Scenarios

The reason for using different subkeys for different purposes is to separate the functionalities to achieve the greatest possible safety without restricting their usability. They can be treated and stored differently, depending on their purpose and security needs.

Subkeys are key pairs, but associated with the primary key. There are differences between Sequoia PGP and other OpenPGP implementations in how keys are structured by default when they are generated. Sequoia PGP generates a primary key for certification and respectively subkeys for authentication, signing and encryption.

The primary key should be the most protected one and therefore stored offline where no one can have access to it. For this reason, the best practice would be not to publish the primary certificate. Instead it makes sense only to publish certificates of subkeys, to avoid that other people use the cert of the primary key. Again, this is not a security consideration, but if people use the primary certificate, it will become difficult to keep the primary key offline.

In this scenarios subkeys are the ones to use for frequent work. Then you just need to publish the certificates of the respective subkeys. It makes sense to rotate them more often by revoking them faster and let them expire earlier than the primary key. The primary key can be used to revoke a subkey if it's needed.

To prevent losing data if an encryption subkey gets lost, it's necessary to have a backup of it in a safe place.
In case of a signing key, it is not as important or even not recommended to have a backup file. This is simply to minimize the risk of key theft by avoiding storing it in two different places. In case of loss the functionality will not be limited, signatures made previously with that key still remain valid and for future signatures you can easily generate a new one using the primary key.

Just a site note, in some countries there is even more a need to separate keys for encryption and signing in terms of key disclosure laws. For example in the UK and in France it can be construed as a crime not to decrypt and/or hand out a decryption key to law enforcement agencies if recommended, even without a court order. In this cases the rest of the key material should remain safe.