It is only when the user tries to run python on the terminal that the system (I presume the shell) detects that the program does not exist, and it then executes another program to inform the user.
If you put python as the #! interperator for a script, then bash will complain that interperator cannot be found.
If it is used as a command as part of a script, then bash does not call the normal command-not-found program (which advises you to install it), but just prints to stderr that the command was not found.
It's unfortunate that so many machines that this poster is working with are getting malformed PATH variables with the priorities out of order, but it should be a simple fix to the PATH to correct.
It should also probably be noted that the Microsoft/Windows Store installed version of Python is the official Python.org release. (It's CIed, and CDed directly from Python.org just as with any other release binary.)
Windows solution in this case is a lazy hack that makes the system more brittle.
As an aside, Linux distributions tend not to have this sort of PATH management issue because (for better or worse) they tend not to modify PATH when installing software.
$ head -1 /usr/bin/dnf
#!/usr/libexec/platform-python
RHEL 8 uses a separate internal copy of Python for dnf, so yes, you can run dnf without the package which provides the python command.