Disclosure: I work on 389-ds at SUSE, so I have a lot to say about LDAP, and why I don't want to re-implement a new LDAP server.
As mentioned, the main goal is "all in one" to avoid the FreeIPA style fragility from using lots of moving pieces. Making everything tight knit gives us a lot of ability to change and adapt to what we need, rather than being bound by what other projects want to do :)
It depends how you look at it - as a professional LDAP developer, I know the ins and outs pretty well, and the issue is that both LDAP and Kerberos "limit" our thoughts on a design. If we come at a problem and say "lets use LDAP, now lets solve the problem" we will be limited by LDAP's ability. But if we say "Here's our problem, how could we solve it?" we can take a completely different approach. So there are many parts inspired by the GOOD bits of LDAP and there are many parts that are completely different.
The main reason to do Kanidm is that it's "all in one". I've had a lot of experience with FreeIPA and have learnt that the microservice design is hard to test and hard to make reliable at scale. So a key goal was to be able to create a single bundle, that we can test end to end to ensure reliability.
That's nice. (I too think it's simpler to get everything okay well tested, when it's all in one place, rather than different software, possibly from different vendors, that's supposed to integrate with each other to accomplish the same thing.)
Also nice that it's written in Rust. And that you've chosen the MPL 2.0 license.
And that Kanidm is an OIDC Identity Provider, I've been looking for that :- ) And WebAuthn
(Keycloak is nice, however it's Java and thus a bit resource intensive (RAM), and some other things.)
There actually is a plan and set of designs that worked towards these parts. There was a lot of foundational work, and currently the goal is the integrations on top.