Excellent points.
I believe nostr:npub1m3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqhqa5sf is working on better documentation of the NIPs; his projects will be worth keeping an eye on.
Additionally, the next step beyond documenting best practices is implementing them. That's why one of my projects is a C++ Nostr SDK. Reliable, stable, easy-to-use dev kits will go a long way to fighting the entropy.
Well, code is just documentation that can be read and interpreted/executed by a machine. Dynamic documentation.
So, an SDK is essentially documentation of one project team's "best practice for implementation" of a particular NIP.
It's more reusable than a mere implementation in a larger application because it's "Just the NIP, sir".
It never ends.
Well, no protocol ever truly is completely finished, but it makes sense to document wider consensus, mark mature docs as "good-enough to finalize", and then not expect any broader application of them, until they reach the next "good-enough to finalize" stage.
There will always be some bleeding-edge implementations or experimental docs, but I'm not going to chase down every hare-brained scheme some developer came up with (regardless of how popular his client is), and solidify it in the SDK.
That's not what an SDK is for.
