> IMO, this makes it the 'system' Python.

"App Paths" entries can be used like versioned symlinks in POSIX. For example, an "App Paths" entry for "python3.exe" can refer to a particular installation's "python.exe". That said, "App Paths" is only used by the shell API, not CreateProcessW(). The potential for inconsistency and confusion is a significant downside. 

> the py.exe launcher could be added there instead

Python's installer puts the launcher in either the Windows directory or a directory that's in PATH, so there's really no need for an "App Paths" entry. 

> Windows Store package manages this correctly in line with its 
> PATH management

The store app adds a user "App Paths" entry for the versioned executable name, such as "python3.10.exe". Unfortunately, when searching PATH and "App Paths", the shell API only tries to append ".exe" if the name doesn't already have an extension. Thus running "python3.10" from the Win+R dialog fails, but running "python3.10.exe" succeeds. To work around this, one can add a second "App Paths" entry for the name without ".exe", e.g. "python3.10".

The store app doesn't add "App Paths" entries for "python.exe" and "python3.exe". It's probably for the best, particularly for "python.exe". Entries in "App Paths" take precedence over PATH in the Win+R dialog, but CMD's `start` and PowerShell's `start-process` always search PATH first.