Shared state is great as long as you control it.
Databases are a giant blob of shared state, albeit a carefully-managed one. People complain about them all the time, but databases completely take over in huge areas of the application development landscape. There's a reason for that -- consistency is a very powerful simplifying assumption (giant understatement). Getting consistency in erlang may be possible, and of course you can still use a database from erlang, but the philosophy doesn't quite line up.
Databases already offer isolation between transactions. And they naturally work with immutable structures similar to functional programming.
For most applications out there, HA means replicating a database, and when it goes down (which is actually quite rare), you lose a little time doing a failover.
Hot code loading means uploading a PHP file with a new extension and "mv"ing it over the old one. Need schema changes? PostgreSQL offers transactional DDL (e.g. ALTER TABLE).
Any error in the database usually just causes that one transaction for that one request to fail. Any error in the application usually just crashes that one process serving that one request.
Philosophically, using erlang is trading consistency for availability. Given that it's easy to get good availability using normal applications connected to a database, using erlang is somewhat of a niche.
I have spent some effort learning erlang, and I really like it in many ways. I bought the new book and I like it so far. I have no problem with the syntax and I find it enjoyable to write in (though I haven't written any large programs). There are certain projects where I think erlang would be a great choice, like management and control of a cluster system. Obviously it works for telco-like things, too, but I've never developed anything like that.