Reasons to store users' data in LDAP instead of RDBMS
It is often said that using LDAP is a good way to store data about users. That's beacause users' "directory" is hierarchical and it changes rarely. But in my opinion that doesn't exclude using RDBMS. What might be reasons to use LDAP? I guess that storing multi-valued fields or adding custom fields in LDAP might be easier but it can be done in database too (unless you have many records)
Answer
Interoperability, as has already been mentioned, is very much in LDAP's favour with some types of server software, although much of the software that integrate with LDAP require a specific schema so it's not necessarily as simple as just installing and configuring an LDAP service and off you go - you might need to add new elements in the schema for each app you want to interact with, and each application might have different limitations with regard to authentication (for example plain text password fields, password fields as MD5 or SHA hashes, etc).
A good LDAP service requires a fair bit of configuration knowledge, more so than creating a simple schema in a relational database. SQL DB's are still a fairly interoperable option and LDAP support is not as dominant as it once was. LDAP used to be the only option years ago, but many applications (like Apache) and operating systems (like Linux's PAM) can authenticate against SQL DB's like MySQL just as easily as LDAP servers as it's all handled by drivers that abstract the interface.
Where LDAP really shines is scalability. If you specifically want a place to hold user accounts for authentication and want to scale to multiple replicated servers - and handle tends of thousands of authentication requests a second, LDAP is an great option.
It's not that modern RDBMS's don't scale it's just that LDAP is (typically) even better at this because of the way it cascades replication through different tiers; particularly assuming you have a typical authentication database setup where it's mostly read-only with relatively few write operations, so you only need one way replication with all writes coming from a single source of truth.
Really though, an LDAP server is something to consider if you have a specific need to do so, like a specific application you want to be able to interoperate with that only integrates with LDAP, or if you are building a highly scalable authentication system (e.g. for an ISP or for a super-scalable web application - where you plan on having more than a couple servers dedicated just to authentication, and where they may be spread across the country or even across the globe).
The point someone has already made about having an LDAP front end on an RDBMS is very good one. A few companies - including Oracle (who have a vested interest in RDBMSs, of course) - have products that do specifically that. If you don't want the overhead of managing an LDAP service, or if you just want to manage all your users in a DB you can create views/joins with, but think you might need an LDAP service later, than it's a good option. OpenLDAP also supports a shell back end which can take in data from any source, including an RDBMS; I've used it with MySQL and it works well, although can be a little fiddly to set up the first time if you need to support a specific LDAP schema.
In summary, LDAP is great, but it's situation specific to interoperability and extreme scalability. If you have limited resources to manage and support one, it might not be worth the hassle of supporting, but if you are planning services like UNIX hosted POP/IMAP/SMTP or other third party software integration then it's certainly worth doing (and may even be your only viable option).
Oh and lastly be wary of what LDAP server you use if you do decide to implement one! They are not all created equal and the differences between them (in terms of performance and ease of management & configuration) can be quite stark.
OpenLDAP is a pretty safe bet, scales well and is fairly easy to use. Some applications work best / come with specific configuration files for a specific LDAP server (e.g. a lot of software on Solaris assumes you are using Sun ONE directory server) which you might not otherwise want to use - either because it doesn't perform as well, or is a pig to configure, isn't well supported, etc.