Your very first sentence proves the point in the article, actually. What exactly do you mean by "users and roles"? Do you mean system level users and roles, or users and roles that are defined only in your environment in the database? The fact that I would have to ask this question lends creedence to the argument for using LDAP over a database for certain tasks, because the LDAP data schemas are generally widely published and standardized. If I talk to an LDAP user from just about anywhere and mention "inetorguser", they know pretty much what I'm talking about and what it implies. Not so with your users and roles.
Further, you could well be right that your particular implementation for user provisioning might be "better". I have no idea, really, because I have no clue how you're defining "better". To my mind, not having to devote the resources of database admins, schema designers, developers and the like to do something that has already been done a thousand times over (and is proven to work a thousand times over) is "better" for two reasons:
First, it costs less in terms of time (and probably money)
Second, the data layout for users is standardized. This means that if I come into your environment to do work and you're using ldap, I already know what I'm dealing with, because as an admin, I've dealt with LDAP a million times before (and probably with the schema you're using for user data, as well). I have *not*, on the other hand, dealt with your custom creation a million times before. This goes for developers as well as admins.
This is all without even mentioning that what I'm talking about in the article is only *marginally* about user *provisioning*. It's really more about user data storage and retrieval, which is an area where LDAP is clearly an accepted standard over custom mysql schemas. For example, no email client that I've used can grab their addressbook information from a mysql server - and even if they could, am I to expect my users to be able to fill in information about the site-specific data schema? Or worse, am I to expect the admins (er, me) to go and configure (and keep updated!) all of my users' email client configs? No Bueno(tm)
I'd like more detail on which aspects of LDAP you think developers would find more difficult? Have you ever coded using php_ldap, JNDI, python-ldap, Net::LDAP....? I've used all of these as a developer, and have found using them to be far simpler than coding against a database in most instances. To tell the truth, the models are fairly similar, and where the differences exist, I believe 9 out of 10 developers would *prefer* LDAP, and the 10th developer probably works for Oracle or something. I'm confident of this because I support developers who have told me as much, and it's usually these developers that I have to keep away from the LDAP server for fear they'll store inappropriate data in the LDAP server because it's so *easy* to code against.
Please clarify your arguments against using LDAP, and cite examples where you've experienced pain with LDAP. It's certainly possible I've missed your point, and I'd love the opportunity to help if I can. :-)