Yes for a solution for arbitrarily large networks cn=config could be
more scalable and cheaper. But that's not true for a small server for a
small organization that doesn't need the extra complexity.

I don't want to understate the pros of cn=config, I just state my
opinion about the cons. If you tell me the maintaining slapd.conf is too
costly in terms of developers energies I've nothing to say. But I don't
agree that cn=config is always better.

There is not much difference between a slapd.conf and an .ldif of the cn=config information, just a different text format.

But the benefits come from synergy of using ldap as the internal config structure should not be overlooked, there are strongly typed data storage, fast lookups, and reams of boilerplate code being thrown away. But presently we still need a binary (executable) to turn that cn=config text format into something slapd can boot up and use. Given the text -> cn=config code is present already, is there really that much work to leaving it there?

But can we reliably create the slap.d config file with deployment scripts directly, as it also seems to just be text.

Other than being nicer to read, is there really anything wrong with the (already) text format of cn=config on the disk ?

There are some gotchas with the conf file, in any case. Config options mean different things in different places etc.,