This is going to be context dependent. It will depend on the sophistication of the person writing the code, if they have a CI/CD pipeline (which cuts multiple ways), how many users of the code there are, what packaging environment you are using, … . Even if you are “just running out of git”, you still want the ability to get a sensible version! Editable installs are (and always have been) core to my personal workflow and to many of the scientists I support [1]. In cases where you are running data analysis it is very common to care exactly which commit the results where generated with (e.g. to sort out if things are before or after a bug was introduced/fixed) but doing a “release” on every commit is not really sensible.
As I’ve argued else where (Should sdists include docs and tests? - #120 by tacaswell) the “Truth” of versioning is in your VCS, everything else (.debs, .rpms, wheels, .sdists, files dumped in site-packages, …) are strictly derived artifacts [2] and how the version is made available to mod.__version__ can be up to the package. Using dist-info is certainly one (common) way, but it should not be the only way.
My (and putting words in his mouth @ChrisBarker-NOAA 's) point is that we should not write in stone where the threshold of being worth opting into using a process that uses dist-info should be nor what "deserves a version based on how the module was made importable.
Fundamentally, at runtime you do not care (and in my view should not care) how the module you are using was installed nor what one (of the possibly multiple overlapping) packaging ecosystems thinks the version should be, you care what the version of the module object you have in hand is.