What about the UX for managing all these keys? Every time you try a new app you must create a new key using your master key, so where does that master key live?

In an offline hardware device?, then it will be incredibly hard and only 5 people in the world will do it, everybody else will just paste nsecs and the protocol will be bloated for no reason.

Or in an online device or server that keeps running 24/7 and answering requests for creating new keys somehow? Now we have just recreated NIP-46 but 100 times worse. 

 > In an offline hardware device?, then it will be incredibly hard and only 5 people in the world will do it, everybody else will just paste nsecs and the protocol will be bloated for no reason.

Reading and writing or typing on a keyboard were once specialist skills too. The world adapted somehow. FIDO2 keys are quite common.

Don't pull a Luddite here. 

 The ux would remain largely the same as it is today, since the master keypair wouldn't require frequent interaction, making it suitable for cold storage use cases. The only additional steps would be to attest the relationship between the keys initially, and in the event of a catastrophe or key rotation, where the master keypair would voluntarly inherit the reputation and value of the rotated account and attest to the new one.
nostr:nevent1qvzqqqqqqypzqs9eep0ll6hurjkl3sc2fewgses07mjfwxsdcu3at2m8fd0xrdz3qyv8wumn8ghj76mgv968yafwdehhxarjv4jjumt99uq3wamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmny9uqzpngc7pjx2fl38hs3t3vdvzar3emc00mxgn73ydt0kq9l4g7d0r09xyvj4m 

 I completely understand your point, but it's not what I was trying to convey. I'm thinking about how we can create a more robust security model for accounts, ensuring that users can maintain their reputation, wot, and at the end the value of their account.
My idea is not to have one subkey per device, but rather to have a master keypair and an active subkey (which can be improved upon in the future to accommodate more use cases, but for now, let's focus on one master key and one subkey). The master key becomes the source of truth and designates a subkey as the current one in use.
In the event that the subkey is compromised, the master key can inherit the reputation and data generated by the subkey, serving as a kind of backup and support. The user can then migrate to a new subkey and update the master's metadata to attest to the new subkey in use. This approach maintains reputation and aggregates it in a single, well-known source, while also solving the poor user experience of rotating public keys.
Currently, the most frequent way i've seen people dealing with this case, is publishing a kind1 message telling everyone, which is often only published once, making it likely that a significant portion of contacts will miss the update. This new approach would improve upon that, but its just an idea tbh. 

 The idea is the same in that you end up with multiple pubkeys or you re-broadcast with the new key all your past events. But, key compromise always happens at some point and that is a good argument to isolating these points so in a nostr where everybody has multiple pubkeys, people would like to use different subkeys for different points or apps or machines.

But as fiatjaf pointed out, this problem is sort of solved with nsec bunker as here, the master key controls how the key can be used and you can give sort of sub keys to different systems without third parties needing to care or know about these sub keys. 

 Yea, but then you make everyone rely on 3rd parties bunkers, or push them to run a server 24/7. Also in that way subkeys will pollute relays since they are just made to trigger the bunker and get a signature from the master pubkey 

 Those pubkeys are very low bandwidth. The (personal) bunker listens for one pubkey per client you use.

I want a bunker in my phone. That's always on.