I kind of feel like you’re taking one of the specs from nostr - the first one written - and calling that the whole protocol. Then you’re comparing all of the atproto specs to that one spec.
The substantive difference is that we didn’t do a mix & match spec process because we knew the ambiguity of spec support causes problems, just as it did with XMPP. Protocol specs only get implemented a few times. The meaningful developer choices are in schemas and business logic.
the spirit of my comment was more psychological than technical. nip-1 successfully nerd-sniped my brain into thinking it was easy to get started with a simple, barely functional client. (even though, you're right, at scale, everything gets complicated and is not easy.)
perhaps this a roundabout way of hoping there is already a developer-focused quick start or tutorial for making a barely functional AT client. it either already exists, but i didn't look hard enough for it, or it might only be one chatgpt or claude prompt away.
But that's essentially the whole protocol. You can implement a client or a server reading only NIP-01 and it will be able to interoperate with the rest of Nostr.
Reading and implementing NIP-01 can be done in an afternoon (or a weekend if you're taking your time), and it gets you relays that can accommodate multiple clients and applications. From the client perspective, only implementing NIP-01 gets you a simple Twitter clone with an identity that belongs to you.