Why do PGP master keys only have a single subkey, and tie certification with signing by default?

Question

After learning more about PGP subkeys and how to split apart the roles of (S)igning, (E)ncryption, (A)uthentication and (C)ertification, I discovered that in most cases(?) a default master key has a subkey to separate out the job of encryption:

pub  2048R/AAAAAAAA  usage: SC
sub  2048R/BBBBBBBB  usage: E

Here, AAAAAAAA is the master key. S allows signing content, C allows creating new subkeys. (One benefit of this being that you can give AAAAAAAA a longer expiration time than BBBBBBBB and then create a new encryption key with AAAAAAAA because it has C usage permission.)

However, it seems to me that the following would be no less secure for users working off a single machine, yet provide more security for users who wish to receive encrypted mail from, e.g., work and home:

pub  2048R/AAAAAAAA  usage: C
sub  2048R/BBBBBBBB  usage: E
sub  2048R/CCCCCCCC  usage: S

With this setup, the master key AAAAAAAA cannot sign/verify or encrypt/decrypt, yet can collect trust. Thus, you can give the master AAAAAAAA key a longer expiration time and use it to add new subkeys. By then exporting BBBBBBBB and CCCCCCCC to, say, a separate work computer that is moved around a lot more and is less secure, without the master key, if the work computer is compromised, subkeys can be revoked and new keys added, without losing any reputation.

(You can even go as far as to keep the secret part of the master certification key in a Super Secure Secret Bunker, of course.)

I know that setting this up seemed to be impossible through a GUI (they don't seem keen on subkeys, either viewing or editing, let alone controlling what the master key can and can't do), but my question is:

Is there a specific reason this isn't done with existing PGP implementations? Exporting secret keys to other machines without certification privileges seems like it would be a big security win. (If only GUIs made it easier.) My only possible thought is that importing secret subkeys with a crippled master secret key is maybe not widely supported, as --export-secret-subkeys (in the gpg(1) man page) hints at:

--export-secret-keys

--export-secret-subkeys
       Same  as --export, but exports the secret keys instead.  This is
       normally not very useful and a security risk.  The  second  form
       of  the  command  has  the special property to render the secret
       part of the primary key useless; this  is  a  GNU  extension  to
       OpenPGP  and  other  implementations can not be expected to suc‐
       cessfully import such a key.  See the option  --simple-sk-check‐
       sum  if  you  want  to import such an exported key with an older
       OpenPGP implementation.

Answer 1

When you make different keys for signing data and for signing certificates, then people who "sign your key" must actually sign your certification key, not your data-signing key; otherwise, the Web of Trust won't web past your key. However, when you sign an email, you do it with your data-signing key, not your certification key, and that's your data-signing public key which gets copied in the email.

So separating signature and certification keys is doable, but requires involved people and/or software implementations to be more careful about what they sign and distribute. I can imagine that you might encounter usability issues.