LDAP servers are often used in a web environment and often back user data. Single Sign On is nearly always backed by an LDAP data store. That one should always use a (relational) database rather than other data stores is... poor.
The key with any data store is to use the one that is most appropriate for the data. Sometimes the data fits better in a traditional database, sometimes it is best in a nosql style data store, other times its a directory. One should use the appropriate data store for the data.
The thing that LDAP excels at is fast lookups for rarely changing data. Going back to the user data (as an example), the email, password, name, and roles rarely change.
Similarly, cached data often fits well into a directory where you compute the data and then load it (which is then frequently read).
Directories, however, don't like frequently updating data. Its a trade off - you can optimize for reads if you penalize writes. Rebuilding indexes on the fly is not something that LDAP does well when comparing it to a relational database.
How (and how well) transactions work are still within flux within LDAP. If you want to have multiple updates be a single atomic operation, this may cause problems.
Referential integrity (foreign keys, unique constraints) does not exist within LDAP. Similarly, if this is what you need, you may find it difficult.
While one could pack JSON data into a field within LDAP, LDAP itself doesn't try to do the data structures that are present in other databases.
If you are doing a not-occasional number of writes or updates (and thus impacting performance), 'joins' of data rather than filters, or want faster consistency than ldap replication offers you may find that LDAP data store is not appropriate.
But as a data store for stuff that rarely changes, it is often one of the best.