Basically, any yoyo could set up a fake site and a certificate for it that "proves" you're really talking to your bank, down to the right colour in the address bar and a nice "YourBank, plc" tag replacing the yourbank.co.uk.pwn3dj00.biz hostname. That is why ostentiably why browsers whine so much about self-signed certificates.
To solve that problem, x509 relies on a hierarchical structure, neatly reducing the problem from millions of unknowns to only about 650 (and counting). The upside here is that you can tell your users that because the other side's certificate is signed by one of the certificates in the root CA list in the browser it must therefore be "safe", neatly forgetting to explain just what that means. (It means you'll be protected from whomever all those 650 browser-blessed root CAs refuse to take money from, provided none of them fsck up.)
PGP/GPG by contrast would require every tom, dick and harry to understand about the web-of-trust thing, set up a key, go to signing parties, and so on. The web of trust model doesn't rely on a large collection of single points of failure, excuse me, root CAs, but it's a model that only a nerd might understand (even so not all GPG-using nerds really do) and only a cryptonerd could really love. There's a reason Johnny (still) can't encrypt.
Neither is the most brilliant solution to the problem. The x509 model, however, is much more commercialisable than the web-of-trust model; you can have companies take your money and harass you with requirements and give you a certificate back. After that most if not all your users' browsers shut up about untrusted certificates. For a year or so.
So you should see that self-signed certificates are a problem in the sense that they don't guarantee anything whatsoever --unless you know beforehand what signature to expect you don't even know you're not subject of a MITM attack-- but also that neither web-of-trust or root CA trust anchoring is a very good general solution. And that rules locking down some aspects of the root CA rigamole is just so much fig leaf on a broken system.
Personally, I think that we'd be better off to go to our nearest bank branch and get confirmation from the manager that $KEY is what they're currently using to secure their banking websites. How you'd do that? Maybe a business card with a signature on it, possibly the entire key in a 2d barcode on the back. Or maybe a smart card containing the certificate, who knows.
Currently, though, no browser really support user-blessed certificates, nevermind in a usable way. It's either browser vendor-blessed, or OS vendor-blessed (that's micros~1; it seems like the same thing but the CA store is part of the OS, not of the browser, and it'll wipe out your "don't use these CAs please" choices behind your back at the next scheduled system update OR ca store check too).
That wouldn't solve the general case, but if the certificate system would support both models interchangeably you could have a master key for the bank with current-use certificates for things like websites and email signing, and you could have trust signatures where your bank would certify certificates of merchants or merchant organisations they'll do business with. And that sort of thing needn't be limited to banks, of course. But since the certificates aren't limited to one CA's blessing, we've more-or-less done away with the root CA problem of being forced to trust them all lest some things stop working, even if that prevents us to distrust some other things the same CA blesses. Now for a much better way of having indivudual users choosing which CAs to trust.
So I think that neither model alone would do, and neither would disregarging all endorsements as you'd do with self-signed certificates. In fact, even such a flexible system, while a massive improvement over the two incompatible systems we currently have, won't be enough. There's some more features we'd need, like selectively revealing who signed what and other privacy measure. But that's well beyond the scope of this latest attempt at patching up a thorougly broken system.
At the end of the day, though, we'll find that the modeling is the easy part. The hard part is doing something useful with the models. For a long time now we've ignored that last bit, and so it's no surprise that it's increasingly coming apart at the seams.