There's no question in my mind that the whole thing is a racket and militates against security (you generally don't even know all the evil organisations that your browser implicitly trusts - and all the organisations that they trust etc).
There are certainly other options too: here's my suggestion-
The first time you go to a site where the certificate is one you haven't seen before, the browser should show a nice friendly page that doesn't make a fuss about how dangerous it is, and shows a fingerprint image for the site that you can verify elsewhere, either from a mail you've been sent, and with a list of images from fingerprint servers it knows about that contain a record for that site shown next to it.
Once you accept, it should store that certificate and allow you access to that site without making a big fuss or making it look like it's less secure than an unencrypted site. This should be a relatively normal flow and we should make the user experience accessible to normal people.
It's basically what we do for ssh connections to new hosts.
The SSH approach is exactly what I was thinking of, where you know the fingerprint of the other side you're connecting to.
I believe verification should be done out-of-band, using some other way (e.g. advertising) to transmit the fingerprint to the users. I've used self-signed certificates to collaborate over HTTPS with people I know in real life, and all I do is give them little pieces of paper with my cert printed on them.
With SSH you usually own both endpoints (or at least trusting your cloud provider).
The example you give with regards to exchanging a piece of paper is very similar. It's ridiculously hard to do such a thing on large scale without trusting intermediaries.
You'd need a strong root key and subkeys that rotate underneath. To change the root key would require signing by the original root and a new message to appear for confirmation.
All this plus something like a notary system to double check all your trusted root keys, would be much better than the hierarchical CA system we have.
No, the question is what to do when you need to rotate them. Because that need will arise somewhere, globally, if we were to run the secure web on trust-on-first-use.
It's not interesting why someone hypothetically did get their root keys compromised, it's interesting how the proposed system would cope with it.
(Downvoting the question is not really a web scale way to build a global trust system.)
There are certainly other options too: here's my suggestion-
The first time you go to a site where the certificate is one you haven't seen before, the browser should show a nice friendly page that doesn't make a fuss about how dangerous it is, and shows a fingerprint image for the site that you can verify elsewhere, either from a mail you've been sent, and with a list of images from fingerprint servers it knows about that contain a record for that site shown next to it.
Once you accept, it should store that certificate and allow you access to that site without making a big fuss or making it look like it's less secure than an unencrypted site. This should be a relatively normal flow and we should make the user experience accessible to normal people.
It's basically what we do for ssh connections to new hosts.