The issues you described, software not appearing, shortcuts missing, are not flaws in the security model. They are flaws in your installation methodology.
When you run an installer as Administrator, many legacy or poorly coded setup wizards default to installing for "Current User Only" (%AppData% or C:\Users\Admin).
You install it as Admin. The files go into the Admin's profile. Then you log in as Standard User.
The Standard User cannot see the Admin's desktop, cannot read the Admin's AppData, and therefore sees "broken" software.
Competent sysadmins select "Install for All Users" (writing to C:\Program Files and C:\Users\Public). If the installer doesn't offer that, it is garbage software, but you can still manually move the shortcuts to C:\ProgramData\Microsoft\Windows\Start Menu.
You mentioned the program wouldn't run. This is almost exclusively caused by developers who are stuck in 1998.
Proper software writes binaries to Program Files (Read-Only for Users) and configuration/save data to Documents or AppData (Writable for Users).
Bad software tries to save your settings directly into C:\Program Files. The OS blocks this because users should not be modifying application binaries.
You do not need to make the user an Admin to fix this. You simply find that specific folder, Right Click -> Properties -> Security, and grant "Modify" rights to the Users group for that one folder.
You have opened a tiny window in the house, rather than removing the front door entirely.
Calling the Standard User model "lipstick on a pig" is a confession of defeat.
Fortune 500 companies, military networks, and banks run millions of PCs on Standard User accounts. The software works because their IT staff knows how to configure Access Control Lists (ACLs).
The Diagnosis: The "trouble" you experienced was not the system failing, it was the system working exactly as designed, stopping a low-privileged user from accessing high-privilege data, and you lacking the knowledge to bridge the gap correctly.