While I agree with the premise and am always happy to see LDAP illuminated, I have long espoused my own view as to why one might develop applications with directories:
In contrast, the standard schema argument presented in the article seems particularly weak because there are literally thousands of published schema available but only a handful that are used across implementations with just a few attributes of consistent relevance.
The most common reason I perceive developers prefer an RDMBS to a directory is familiarity. If they were well-versed in both, they would actually understand that a directory is significantly simpler and easier to manage. An RDBMS has strictly more capability, but it comes at a complexity cost that gets partially masked by training and tools. An enterprise data warehouse does demand an RDBMS, but will usually also demand at least one dedicated DBA.
On the other hand if your application doesn't involve multi-join queries, your system doesn't require rollback, and data retrieval will be more common than change, I argue a directory could be the basis of a very nice solution even where the application deals with things beyond people.
And nothing precludes dumping summary information from the directory into your RDMBS for other needs. The reality is that production directories and relational databases are *both* running in most every mid to large size organization, even though their coexistence is most often coincidental. I think it would be better to see them deployed in pre-meditated architectures that play to their complementary strengths.
See you again on the next installment.