The product is built in a very controlled and secure environment at the core of a company's competency ... code-signing here stamps the product as authoritative and representing the company's efforts.

The website from which you, the customer, download the software often is built and managed under less controlled and more vulnerable circumstances, often with third party involvement. Any bad actor in a long chain of internal caretakers and potentially external hackers can replace the to-be-downloaded artifact HTTPS with malicious junk. Code-signing mitigates this.

For example, code signing can protect against an attacker that can swap the application, but not the signing certificate. It can allow retroactive disabling of a certain application by revoking the cert that signed it. In short: HTTPS ensures the integrity of the download at the time the app is downloaded, code signing at the time it runs.

Because somebody might’ve changed the files on the distribution servers. We’ve been signing executables for decades?

Semi off-topic, but anyway, I have an supportive argument for you: APKs are signed anyway, the signature is embedded in the package, regardless of whether it's in the app store of not, it the signature has changed, you cannot use a new version to replace the previous version without manual reinstallation, it's an effectively safeguard against phishing.

But only the readers of Hacker News can recognize it. I think it's one of the most powerful argument for a walled garden. Not that I support it, but I acknowledge it's still a powerful argument.