That's true for new installs at least. But Android won't let you install an update to an existing app with a different signing key, it'll error out with something generic.
As an explanation as to why Google has gone down this design path, I think this makes sense. Basically it’s easier to maintain compatibility with existing devices this way.
From a security perspective I don’t think it makes the slightest difference. Google controls the logic that prevents updating apps with a different signing key.
There are so many conceivable ways that Google could inject arbitrary code into each process (e.g. silently cause a different “shadow” app bundle to be launched, play with LD_LIBRARY_PATH, play with the Dalvik VM, modify Java/system libraries, etc) or read processes’ memory, that it’s safe to assume that if Google wants (or is forced to) to modify your app’s behaviour or exfiltrate sensitive data from your device then it’s absolutely within their power to do that.
People are concerned about Google editing code, which would be detectable through the signed code section or just basic decompilation and would be a nightmare for PR. But people are apparently not concerned with
1. Nothing has ever prevented tampering with the signature before first install.
2. Google owns and writes the OS.
3. Libraries like WebView are both security critical and updated via ordinary app updates, and are provided by Google.
4. The dex bytecode isn't actually run on modern devices. Instead it is compiled into an executable by code owned by... Google.
5. The large majority of developers are using compilers and other tooling provided by Google.
This is why the concern over this change is ludicrous. When you installed Signal or whatever for the first time did you check the signature? Did it bother you that it was technically possible for Play to substitute code? No. Because you are using an Android phone and trusting the OS developer is a requirement for everything.
And there isn't a "total lack of chances to stop tampering", since the code section can still be signed with a different key.
So why is everybody suddenly claiming a conspiracy here?
The main threat model is that google is influenced into editing a specific app or few for certain users or locations, not that the company is going to turn the entire OS into a backdoor. So most of your bullet points aren't very relevant. This threat model isn't a "conspiracy" either.
From a security perspective I don’t think it makes the slightest difference. Google controls the logic that prevents updating apps with a different signing key.
There are so many conceivable ways that Google could inject arbitrary code into each process (e.g. silently cause a different “shadow” app bundle to be launched, play with LD_LIBRARY_PATH, play with the Dalvik VM, modify Java/system libraries, etc) or read processes’ memory, that it’s safe to assume that if Google wants (or is forced to) to modify your app’s behaviour or exfiltrate sensitive data from your device then it’s absolutely within their power to do that.