I've been wondering: assuming a modern Windows edition (>= 7), and that UAC is enabled, what benefits are there if I additionally use the system as a standard user? From what I understand, the only difference is that instead of just clicking "yes" on the dialog, I'll have to provide an administrator password, but programs will still be prevented from administrative actions without my consent because of UAC.
The DFIR Blog has a great summary of UAC
In the article, the author recommends the Always Notify approach, especially for administrators and critical servers. Besides social-engineering attacks such as the exploits/windows/local/ask module in the metasploit-framework, there are also tens of UAC bypasses. The author covers the techniques and tools to bypass UAC better than most.
The author does not make mention to, and I do not know of a tool or technique to bypass Always Notify -- however, escalation of privilege -- especially to the SYSTEM account -- may be possible through a privilege-escalation exploit and/or a misconfiguration issue (although any-given privesc exploit must not require administrator privileges, which is not necessarily rare, but a condition that must exist for some exploits to work). Misconfigurations typically include UNC path and/or file/folder/service permission issues. Typically, these privilege escalation techniques require an advanced understanding of the Windows environment that even most NT administrators do not posses, however, again, some are available in the metasploit-framework and other exploitation engines (or bundled with exploit kits) -- thus lowering the barrier to entry to anyone with adversarial intent. Other times, admins or admin tools simply leave password in cleartext (or an easily-reversible format) in files on the operating system, on a sticky note, or other lowered-care OPSEC.
Most end users will revolt against Always Notify, but perhaps not the next-lower setting, the medium-integrity process (which many UAC-bypass techniques work against).
As for local or domain administrator accounts for end user machines, it's very bad practice, as users can simply right click any executable and choose "Run As Administrator" to elevate privileges and destroy the power of UAC (N.B., this can also be done via cmd.exe if a separate admin account password is known by any end user). A lot of malware, especially persistence techniques, rely on administrator access (e.g., for Windows service installation). If UAC must be set to something lower than Always Notify, the best strategy is to also disallow any administrator access (privileged access) and provide additional protections against end-user app installation. My favorite platform for Privileged Identity Management is STEALTHbits and this can be combined with BeyondTrust and other privilege-management solutions.
As an additional protection for non-administrator accounts, the permissions on the user-specific AppData\LocalLow folders also allow malware to activate and persist. Another one to look out for is that some orgs will set the AlwaysInstallElevated registry key to allow non-admins to install applications. However, MSI's elevated privileges can be abused and there is even a metasploit-framework module to do so (i.e., exploits/windows/local/always_install_elevated).
Another distinction to make is for elevation prompts (apps can be written to automatically prompt, but UAC behavior can override/preempt this capability). The book Least Privilege Security for Windows 7, Vista and XP covers this and says:
Microsoft recommends that in corporate environments, system administrators should configure UAC to automatically deny elevation requests using the User Account Control: Behavior of the elevation prompt for standard users local or Group Policy setting. This ensures that malware can't intercept an elevation prompt and harvest the credentials of an admin account.
The existing answers covering most of the important things. I just want to add that in case of ransomware the software doesn't need any elevated privileges. If the malware doesn't has privileges to persist somewhere this wouldn't even a problem. If the user has write access to (some of) their important files which is very likely, the ransomware just encrypts it and leaves a good visible notice with further instructions.
Microsoft doesn't consider UAC a security barrier, and thus they often don't fix UAC bypasses. These bypasses are common and easy. See for yourself: https://www.google.com/#q=uac+bypass
The benefit would be that ALL rights would be run as a standard user, not as administrator. Installers that trigger the UAC are far from the scariest things that go bump in the night.
What you are describing is what a standard user would see, not what goes on at the OS level. UAC on its own does not make you secure.