I don't use Erlang much these days (can't use it at my job, not much free time for my own projects), but I follow Erlang mailing lists and blogs pretty closely. The people there are as a rule much smarter than me, so I can only benefit :-) Tony Arcieri, the creator of Reia, recently ranted about the shortcomings of Erlang, and some of the points he raises do have merit, and others not so much IMHO. There are also some good comments on the mailing list about that post here.
Records Suck
Yes they do. There are more dynamic data types available, but only as libraries, not as native datatypes. I miss the built-in hashmaps that used to be found only in the "scripting" world are now built into many modern languages.
Erlang isn't general purpose
Because Erlang only has immutable variables. Or so he argues. I find the argument not that compelling. Mnesia, the built-in database is quite easy to handle and well suited for small-to-medium datasets. For large (or "Big") data sets you want a specialized system anyway -- a relational database, a NoSQL system, whatever. Anyway, there are certainly things Erlang is suited for (distributed realiable systems eg.) and for some tasks it's not so great for (OS-level stuff, GUI-heavy stuff eg.). That's pretty much true of any language I'd say.
The syntax is atrocious
Well, one gets used to it. No, really. The syntax is a little unusual and sometimes just impractical -- for instance, the different expression terminators which make it impossible to copy/paste pieces of code verbatim or move lines around is just not that likeable. Other things just take a little getting used to and work reasonably well. So, while beautiful syntax may not be Erlangs strong suit, the syntax is certainly usable.
The standard library is inconsistent, ugly, and riddled with legacy
For me, this is the biggest practical impediment. I don't have photographic memory, and memorizing the varying naming conventions of different stdlib modules is just... annoying. As is the mapping of some functions to libraries and the language itself. Why is a function to compute an adler32 checksum a language built-in, but modules for list and dictionary handling banned to the stdlib? There are massive violations of the principle of least surprise there.
Strings-as-lists suck
Yes they do. Strings are just too important to handle them as a special case of lists. They are of course, it's just that they deserve some extra syntactic sugar on top.
What doesn't suck
So, there are definitely warts here. The good thing is, they are only that -- warts. As opposed to design flaws, these can (and are) remedied. In contrast, the things Erlang is good at -- easy and safe concurrency, reliability, and so on -- are really hard to solve, and require great effort on other platforms. Designing a program around concurrently running tasks that pass messages to each other has been nothing short of relevatory to me. Once you "get" it, it's just the most natural way to think about a problem. And the built-in infrastructure for detecting and handling failure is just excellent. This, for me, is an easy tradeoff: If I have to create software in the problem space that Erlang excels at, like most server software, especially if reliability is an issue, I gladly take the syntax warts, the uneven libraries et al. and gain a great deal of features that would otherwise be hard to get.