Is there a real point to using "Run as" local admin accounts instead of logging in as a local administrator?

Let's start by setting the scene -- I'm a junior systems administrator tasked with conducting a transition of the company towards a "Least-Privilege" model. This includes removing admin rights from our users, who mostly work with Windows 10.

Now at this point in time, users are (for the most part) using accounts with local admin rights. This is obviously pretty bad, and we're working on changing that. The idea that was put forward by my n+1, following a security audit they've had last year, is to have two types of users:

• The first type will lose admin privileges and, in the event of needing them, will receive a temporary password to an account with admin rights on their computer (which will expire after a bit of time, using LAPS)
• The second type (and most relevant to my issue) is made up of developers -- some on web technologies, but others on some very low level languages, and needing to interact with the registries on a semi-regular basis among other things.
  These guys will have a regular account, with no privileges, and an admin account (or "Run as" account) they will use when they need to run stuff as a local admin. This means entering a login and password everytime the UAC comes up to confirm admin privilege usage. This "Run as" account will not be able to open a regular session, for obvious reasons.

The problem comes with these old-school developers. I'm afraid this will be turned into an office politics issue, since the loss of admin rights might come with a bit of productivity loss (especially for those who use privileges more often) and, more importantly, some frustration.

I can understand where they're coming from. Having worked for the same company as a dev, I get that being local admin is comfortable. However, I'm also familiar with security issues, and know that being an admin on a workstation is a big no-no.

Recently, I've had to present to this second type of user our plans for the future. Needless to say the lead dev of the "old-school" group was not happy about it, and he asked a pretty good question (though maybe coming from a close-minded point of view on the situation) to which I haven't managed to come up with a satisfying answer.

If the purpose of not being a local admin is to avoid the spread of malware or the capabilities of an intruder to exploit vulnerabilities, is there a real difference between a user running privilege-needing programs as this "Run as" admin account and just executing it outright with an admin account in the cas of an infected file?
The lead dev argued that such a policy would be nothing more than a waste of their times, since it would result in the exact same security vulnerabilities as just being a local admin in the first place.

Is this accurate? I'm aware of the claims that "92% of critical Microsoft vulnerabilities disclosed in 2013 can be mitigated by removing admin rights"(SANS, 2016, citing an Avecto study) and other such assertions, and I really feel like being local admin is indeed not a good idea, but is our solution really better?

We're planning on doing a test drive of the new solution in the near future, to assess the potential loss of productivity and determine whether or not we need to find another solution, and I'm afraid the lead dev and others who are annoyed by the idea will purposefully overstate its setbacks.

Depends on your risk spectrum.

As a prevention of a targeted attack, the measure is pretty much pointless.

As a prevention of an insider attack, the measure is pointless as well.

As a prevention of devs installing pirated software and failing to uninstall it before an unexpected audit - sorry.

As a prevention of an off-the-mill malware that infects the sales and accounting departments' computers - well, it works, to an extent - and those should not need admin access anyway.

As a prevention of a gross sysadmin negligentce - well, somewhat, because those develop the habit of writting the password quickly and without really reading what it is asked for.

Other than that, getting dev machines where the most IP resides or the backup infrastructure where everything resides to join the AD is bad in the first place.

It creates a single point of failure. Messing with the policies just makes the devs angry and inventive at bypassing the security theater.

p.s. I am yet to see an AD deployment that is not pwned at domain admin level in 5 years, no matter if the legitimate admins know it or not.