Extremely limited transaction support. In particular, no XA support in common implementations. (I don’t think pervasive XA is a good thing, but one data store and one message queue in the same transaction is a common pattern in my code and it works well.)
Difficulty rolling out custom schemata. The mechanism for adding a new schema is implementation-dependent, and frequently quite invasive (for example, in OpenLDAP you need to modify the server configuration to add a new schema).
Deeply legacy assumptions embedded in standard schemata. The person/orgPerson/inetOrgPerson schemata, which are used very widely, contain most of these assumptions about names.
Poor client library support. I took a good run at using Spring-LDAP to handle the authentication backend for something I’m working on, and could not figure out how to delete an attribute. That, plus the lack of ODirectoryM libraries that really understand things like attribute aliases, makes writing general data-access code against LDAP pretty obnoxious.

I wish it would be used more often and I blame myself for not using it every time I have the weakness to create a “user” (or “player”) table in a DB.

LDAP servers are solid and scalable, the protocol itself is versatile enough to support most use cases, so why am I still creating user tables? Why, despite my will to use it, I still don’t do it?

Maybe because the protocol is borderline fuggly and the client libraries out there suck bags? Maybe I’m just lazy and a tainted LDAP aficionado :P

Any crypted passwords will be inserted as a SSHA hash

You can even trick the schema by adding a 3rd authAuthority of ;basic; which allows you to have the SSHA password in userPassword and the password server authority for everthing else. (However adding basic breaks the web based password change page that apple includes because their code sucks)