Windows – UAC Showing Limited User Account [“More Choices”]

A possible solution is to use two policies in concert:

1. Configure the already mentioned ConsentPromptBehaviorUser group policy setting to Automatically deny elevation requests. As stated in the question, this will affect all programs that run.

2. Next ENABLE the User Account Control: Only elevate executables that are signed and validated policy setting. (From Microsoft) This setting enforces public key infrastructure (PKI) signature checks for any interactive applications that request elevation of privilege. Enterprise administrators can control which applications are allowed to run by adding certificates to the Trusted Publishers certificate store on local computers.

3. Sign any trusted programs with your organization's key and publish it to the Trusted Publishers certificate store on all computers in your organization. More info.

is an administrator account as safe these days as a standard account coupled with the built-in Administrator account when needed?

In short: Still no.

The longer answer...

UAC is not a security feature

Back in the days of Windows XP and previous versions of Windows, it was quite difficult to practice the Principle of Least Privilege, not least in a corporate environment. The principle implied that you would do all your day-to-day tasks using a standard user account. Any tasks requiring admin privileges would be executed using a separate account with admin rights (given that the user had a legitimate need for it).

But Windows XP wasn't designed with this in mind, and there were many quirks and limitations, when running as a standard user - even if you also had access to an admin account. As a standard user, you were not able to click on the systray clock to show the neat month calendar, you couldn't change network settings and the "run as" function didn't work for everything (especially Windows Explorer, and thus also Scheduled Tasks, Printers and other shell folders, if memory serves me right).

Of course there were workarounds for a lot of these deficiencies, but it took a lot of time to discover, document and, well, work around them.

Security is a balance between, well, security and convenience. UAC was introduced with Windows Vista, primarily to detect when admin rights were needed, and to automatically prompt you to authenticate with an(other) account, with admin rights. This made practicing the Principle of Least Privilege a lot easier.

As a side-effect, performing tasks requiring admin rights, while logged in with an admin account, gives you a chance to actually confirm that you want to exercise these rights. UAC prompts when installing software seem reasonable, whereas when opening a normal webpage doesn't.

However, it turns out most users don't use separate accounts and quite a few day-to-day tasks require admin rights (adjusting settings for clock, network, power plan etc.), and would thus trigger an UAC prompt in Vista. This slew of prompts causes most users to

a) Blindly accept any UAC prompts, with no attention to what was actually requiring elevation, or

b) Disable UAC confirmation entirely

With Windows 7, Microsoft made several Windows executables auto-elevate permissions, so if you you're using an admin account, some actions are automatically executed with elevated (admin) rights. This made UAC seem a lot less obtrusive.

UAC auto-elevation can be exploited

So, in Windows 7 there's a built-in mechanism for auto-elevating rights. If this mechanism can be exploited, by an application running with standard user rights, then UAC (which was not designed to be a security mechanism), can be circumvented and you can end up running applications with admin rights, though you haven't been prompted to confirm it.

Turns out UAC auto-elevation can in fact be exploited by injecting code, as proven by Leo Davidson (Windows 7 UAC whitelist: Code-injection Issue (and more)) and discussed and demonstrated by Long Zheng (UAC in Windows 7 still broken, Microsoft won’t/can’t fix code-injection vulnerability).

Conclusion

Seen from a security perspective, it still makes sense to use separate accounts for day-to-day work and anything requiring admin rights. This is the only way to be (reasonably) sure, that no applications run with admin rights, without your explicit authorization.

That said, it's a balance between convenience and security. As pointed out by @GeminiDomino, you could also fill all ports with epoxy, as used by the military. You could also run your computer "air gapped", like Bruce Schneier, so that it never directly connects to any network.

In the end it comes down to if you're OK with having to explicitly authenticate when performing admin tasks or not.