I’m ambivalent over the matter of tests being included in sdists. My (personal) view is that I want the sdist so that I can build the project on an otherwise-unsupported environment, and I can view the source code of the project (even though pure Python wheels include the source, it’s not in “buildable form”). I don’t see supporting files like documentation sources, tests, release scripts, etc, as necessarily part of the sdist - if projects want to include them in the sdist, then that’s fine, but on the other hand, if they want to point users to a project repository for those things, I’m also fine with that. For my personal projects, I tend not to bundle these sorts of thing.
If we want to make it the norm to include tests, documentation source, or whatever in the sdist, then IMO we should be standardising the details (such as the directory in the sdist where they go, a standard means of running tests, building docs, or whatever).
Consumers like Linux distributions who need a published, well-defined source for the project could reasonably contribute a set of shared requirements here, that we could use to drive a standardisation effort. But without some clear understanding of what the requirements are, I don’t see the packaging community being in a good place to agree a standard for this sort of thing. And so far, there’s been little unified input from the Linux distros on this type of detail.