Microsoft said UAC is not a security barrier. But in what cases?

This is not really an answer, but speaking in absolutes with security can be dangerous... so... it depends.

I think when you say "Microsoft said UAC is not a security barrier," this is probably what you mean:

From Security Watch: The long-term effects of User Account Control (2007):

What UAC Is Not

UAC was not deliberately designed to be the most annoying feature in the history of Windows. Rather, this set of technologies was designed to set us on a path where users do not need to expose their systems to potentially malicious code as frequently as they have during the past few years.

In its current form, UAC will not stop really good attackers, or ones who have the help of really good attackers. If the bad guys can't think of any other way to defeat UAC, they will almost certainly resort to asking the user to do it for them. Given the choice of dancing pigs and security, we know from experience that the dancing pigs win every time. Users have learned to dismiss dialogs, and so they will until we manage to teach them otherwise. This results from many contributing factors, including the fact that there are too many warning dialogs, that the messages in them are useless, and that many of the manuals for whatever devices users buy include a note to "please click yes to the security warning dialog to dismiss it."

UAC does not provide foolproof security. In fact, it makes the good old local privilege elevation attack interesting again. This is a class of attack that has largely been discounted because, on Windows, nearly everyone was an admin anyway so elevating to some other admin was quite pointless. That said, UAC definitely changes the nature of such attacks and transforms the rules of the game to be much more like what prevailed on UNIX for more than 20 years.

UAC will not stop bad guys from stealing your personal data. A user's personal data is accessible to that user regardless of the user's privilege. As such, an application, including a malicious one, can access the data. UAC does not, and cannot, change that. It does not eliminate the need to be vigilant, distrustful, and paranoid—attributes we should all instill in our end users at every opportunity.

UAC was not designed to protect an application running with elevated privileges from all attacks by an application that runs with normal privileges in the same login session. While UAC does provide some weak process isolation, it was not a design goal for UAC to sandbox applications from each other.

So what is UAC for? From the same article, we get an answer...

Some of the brightest thinkers in the world on Windows security today, such as Joanna Rutkowska, did understand UAC's purpose. As she put it in a blog post on February 4, 2007, UAC "is a new security mechanism introduced in Vista, whose primary goal is to force users to work using restricted accounts, instead working as administrators" (theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html). She has it mostly right, except I would use the term "enable" rather than "force."

This suggests the purpose of UAC was more about enabling users to give up administrative privileges most of the time, without crippling the user experience. UAC is a set of security features that was implemented for the long-game. It forces application developers to work within the boundaries of a standard user where possible, so that users won't need to elevate privileges when they should have been able to work without administrative permission levels.

For your average user, if they don't have administrative privileges on the machine, it will likely be enough of a barrier to keep them from running an installer that requires administrative privileges. But it is by no means a fix-all solution for security.

Bonus Material: Here's a good discussion of UAC from an IT Perspective on RunAs Radio (Episode 376). Richard Campbell carries a recurring theme through RunAs Radio over the years, that if IT has configured things correctly, and the user is doing what they're supposed to be doing, they should never be blocked by a security barrier. It's a lofty goal, but it really is the ideal balance.

I'm going to step out of this question for a moment and take into account the context of another question you've asked: Can I configure Windows Defender to reject competing AV programs?

At your scale of about 30 machines... you might want something like Group Policy as a tool to work with to start locking down machines a little more. But since you're not on a domain-controlled network, you may have to settle for Group Policy's little brother: Local Policy.

Here's a specific group policy object that might be helpful: User Account Control: Behaviour of the elevation prompt for standard users. This setting configures UAC to automatically deny privilege escalation requests. Unfortunately, locking down machines like this will result in more help desk requests if the users don't have the software they need... or the software they use requires administrative privileges.

The phrase "security barrier" can be ambiguous. I think it may be more useful to consider the concept of a security guarantee, sometimes called a security boundary. More here.

Basically, a security guarantee is a statement about the intended behaviour of the software.

Any way to violate a security guarantee (within the appropriate scope) represents a security vulnerability, i.e., a bug or a design flaw. In the case of a security vulnerability in Windows, Microsoft's general policy is to at least attempt to correct the problem. In most cases, this means a security patch, usually via the monthly cumulative updates.

NB: this is not a legal or contractual obligation.

So what about UAC? Well, it depends on both the scenario and the system configuration. Let's go through some of the more obvious and/or interesting cases. [Note to OP: I think you're mostly interested in the last case, so feel free to skip straight to the bottom.]

Default Settings, Admin User

In this case, when you attempt to perform certain tasks that require administrator access, you get the Yes/No dialog.

There is [I believe] a security guarantee that no application (which does not already have administrator privilege) can press the Yes on your behalf, and that the information provided by the dialog about which application is being launched is accurate. [Proviso: I'm not entirely sure what the story is concerning potentially malicious accessibility applications. Can anyone expand on this?]

But in this case that's all irrelevant, because there isn't any security guarantee that an application cannot obtain administrator privilege without bringing up the dialog, and in fact there are a great many well-known techniques for doing so. More here.

Always Notify, Admin User

If you have turned on the "Always Notify" UAC setting, then [I believe] there is a security guarantee that no application can directly gain administrator access, via UAC, without the dialog appearing. More here.

... but still no guarantee that the application will use the admin privileges in the way in which you are expecting. You get to see which application is being launched, but it is your responsibility to check that it is the one you were expecting. Also, you don't see the command line by default, only if you ask for more details; if an application that you trust has dangerous command-line options, a malicious application might take advantage of that, hoping you won't notice them.

... and if any third-party applications are running with admin privilege, they might have vulnerabilities allowing a malicious application to take control. Windows does take some steps to mitigate this risk, e.g., you can't just use a plain old shatter attack, but it can't eliminate all possible methods one application might use to attack another.

... besides, in a typical enterprise environment you can take advantage of the fact that UAC doesn't operate over the network, as described in Joshua's answer. This sort of attack is I suspect even easier and more practical than it sounds.

In practice, these issues significantly limit the effectiveness of this security guarantee, even in the absence of any security vulnerabilities in Windows itself.

(Such security vulnerabilities have existed; for example, Joshua points out that at one point the Task Scheduler allowed an admin user to create elevated tasks without first requiring elevation. Once discovered, it is likely that they will eventually be patched, but they are also likely to be considered low priority.)

[The current user registry hive provides a huge attack surface for a malicious application to attack elevated applications, particularly if you can make changes before the elevated application is launched. Does anyone know whether there are any standard techniques around this? The most obvious approach would be to put a malicious DLL onto the user's PATH, I suspect many applications would be vulnerable to this simple attack.]

Non-Admin User With An Admin Password

This is the case where the logged-on user account is not an administrator, but the user knows an administrator password. All the previous caveats apply.

... plus, a malicious application might mimic the dialog to capture your password, as already discussed in Michael's answer. There are some mitigations in place to make it difficult for a program to use an administrator password to gain admin privilege, but my understanding is that this is not a security guarantee. [Can anyone confirm whether there is a known way to elevate once you've got an admin password? Perhaps via the Task Scheduler, for instance? In many cases this is moot, I guess, since once you've got the password you can use it to RDP in or access the C$ share or whatever from another machine.]

The only really safe approach here is to never provide the administrator password when prompted; instead, switch user and log in with your admin account whenever necessary. Of course this is enough of a pain that only the most punctilious systems administrators will stick to it consistently.

... obviously, if you're doing that, you also need to follow good hygiene in other respects, e.g., you don't download an installer in your non-admin account and then run it from your admin account. But then, you shouldn't really be running a web browser from your admin account either, so catch-22.

Non-Admin User Without Admin Password

We're on firmer ground here. There is an unambiguous security guarantee that a non-admin user will not be able to run an application with admin privilege without providing an administrator password. This isn't new to UAC, but UAC doesn't remove the guarantee either.

Vulnerabilities violating this guarantee are usually called local elevation of privilege vulnerabilities. In most cases they are considered lower priority than vulnerabilities that allow remote attacks, but Microsoft will usually patch them reasonably promptly.

[OK, that depends on your definition of "reasonable". :-)]