I am not sure the below answers your question, but let me just add it anyway:
Elevated Rights: In a secure desktop environment (where users operate as standard user without admin rights) you use "elevated rights" to install instead of "admin rights". This means that regular users install with temporary elevated rights, and this is slightly different from normal "admin rights". For these installation scenarios you need to make sure to use secure properties or the installation fails. One should note that even if you use secure properties, others things could make the install fail in elevated rights scenarios (other custom action issues and InstallShield specific-issues for example). There are lots of details here.
Client & Server Processes: An MSI installation has both a client process (running as user context) and a server process (running as a local service with all access needed to modify the system). The latter process does the work of installing and the client process shows the GUI and kicks off the real installation. At that point the client process hands the server process the installation session, and any properties that are not set secure will not be available to the server process as they will not be "handed over" by default. This is what secure properties are for - they will be passed through.
SecureCustomProperties: The special property SecureCustomProperties holds a delimited list of the properties that should be available in the server process. Only UPPERCASE (public properties) can be specified.
Restricted Public Properties: Now we arrive at this part of the MSI documentation: "In the case of a managed installation, the package author may need to limit which public properties are passed to the server side and can be changed by a user that is not a system administrator. Some restrictions are commonly necessary to maintain a secure environment when the installation requires the installer to use elevated privileges." So in essence there are restrictions to limit what an "elevated user" can override in terms of installer properties. How the properties are passed in detailed technical terms is not documented - as far as I know.
Windows: Changes in how the Windows operating system works sometimes interfere with MSI operation. Hence it could be that it is not sufficient to set these properties secure to get the install to operate correctly.
Custom Actions: The use of true "elevated privileges" is also made difficult because the implementation of custom actions in MSI is very complicated. Very frequently there are errors in vendor packages that may trigger problems when run with "elevated rights" as opposed to "admin rights". Often people open a session with "real admin rights" (for example via a dedicated distribution system such as SCCM - Microsoft Endpoint Configuration Manager) to allow the installer to install without any errors relating to elevation. Or they just kick off the installation from an elevated cmd.exe.
Benefits of MSI: One should be reminded that MSI has succeeded based on a number of critical benefits over previous deployment technologies (despite its flaws).
Links:
