In our case (Spyder), we maintain (fairy sizable, complex and varied) user and developer documentation in separate repos from the code it supports (for multiple reasons), so its not (easily) possible to include in the sdist even if we wanted to.
Tests, on the other hand, are already included by default at least with Spyder’s stuff, since by convention there they are included “inline” in a test (or is it tests 
) subdir of each level of the subpackage hierarchy.
Our best practice across the various projects I maintain is to always run the tests from the source on the installed wheel. For each Python version and platform in our CI matrix, we do a clean sdist and wheel build (with build, of course), install the wheel in a clean env, and then run the tests from the source against that, using either a src dir, tox and/or python -I, plus pytest --import-mode=importlib, to ensure isolation from the source tree and we’re always using the installed copy. It isn’t as important that the tests themselves work when packaged for end-distribution, but rather than the code under test works.
I ran into this limitation myself with some conda-forge packages I’m one of the maintainers of. Is there a reason that the official recommendation is to use the sdist, even though I’m pretty sure git clone/tarballs are supported as well, which would bypass the issue and ensure the full source is available?
I recall this as well, but after some browsing and searching, I can’t seem to find it.