Yeah, that's a good point, but the readmes that I've seen written by those who wrote the code themselves are not much better. Sure, they know what it's all about, which is precisely why it oftentimes isn't much help for a user.

What's needed is someone who'd read the initial readme (written by the guy who wrote the code itself) and ask questions about the parts that were "too straightforward" to be included, or weren't explained clearly enough, or to bring down the general overview back to Earth.

And if there's yet another person who'd go over this second pass, and keep it from being too dumbed down, even better. Keep it to the level of the average user. That requires knowing the kind of person who'd likely use the program.

I‘m sure a lot of people who correct text, add references, structure and pictures to a readme would disagree with you.

I‘m not sure if you‘re a coder but it you are, you should know that coding and usability are two entirely separate things.

Why does it have to be documenting internal designs, architecture, and all that? Why not app user manuals or install guides or any of myriad other sorts of documentation?

Just because one specific scenario may not be suited doesn't mean no scenario is suited to what op is proposing.

I mean first, what kind of projects are we even talking about, libraries? APIs? Apps? Command line tools? Etc?

Because the technical writing needs vary depending on what kind of project. They don't all require coding skills for success.