I use several, but Advanced System Care does some inoculation against common threats. Although, I'm not sure that's what caused it.

It's generally a solid product, it's one of the few system optimization products I've seen on the market that are actually worth paying for. But, I'm using the free version right now because it's hard getting USD to pay my bills with.

I'll run it again to see if it's something it did, but it's a bit of a mystery as to why that file would end up with those permissions unless I did it and can't recall doing it. But, even then, the admin account should have just gone around it without any trouble.

EDIT: http://www.iobit.com/download.html looks like they have some new software that I haven't yet tried. It's interesting that they're now making a replacement start menu for Win 8. Not quite sure what to make of that.

Have you tried running the Microsoft Fix It for this problem? This should reset the access permissions for the hosts file and restore it to its default state.

Another option is to reboot while hitting F8 and choose Repair your computer, then choose the Command Prompt and use it to navigate to the hosts file and delete it. The recovery environment is not limited by Windows' normal protections so you should have no trouble deleting the file from there. It will then be recreated with default permissions and contents when you reboot back into Windows.

Yeah well, system restore works for things you do regularly. The last time I edited my hosts file was many moons ago.

AFAICT this only works if the permissions aren't messed up. If admin can't read or write to the file, neither the manual nor the automatic fix will work.

Actually, Hosts file has Full Permissions on Administrators and System, and Read & Execute (and Read) permissions for users. One of the "Security Suites" you are using messed it up, but an administrator can "Take Ownership" and restore the proper permissions.
It's not MS fault, it's a third party control that messed it up (just like Avast had flagged TrustedInstaller.exe as a rootkit, messing up my OS once).

I've updated my post with a better method using the recovery environment. This should work since it's it's own thing running outside of Windows. :)

I'm not following. The problem here isn't a third party, the problem here is that MS has a screwed up ACL implementation wherein they're combining it with their older flag system in a way which doesn't quite work.

The account in question had full ownership of the file in question. It had full access to the file and ultimately, when you looked at both the admin permissions and the owner permissions they both said full access.

But, that wasn't really correct as the users group conflicted with that. On top of which there was an additional read only bit set on the file which wasn't reflected in all of that.

So, even though the permissions tool itself said the owner had full access to the file, that was not at all correct. The owner had no access to it at all.

In other words, a 3rd party app can change the permissions potentially, but the rest of that is completely MS' incompetence. I've seen it before where they haven't bothered to think their UI decisions through leading to a lot of lost time trying to figure out precisely what the problem is.

The dialog itself said that owning the file was sufficient to gain read access to it. Which is not true.
I'll give that a go. It seems to be working, but I'd be happier knowing that the permissions are as intended.

Not sure about the read-only part, I don't think ever having troubles due to it.
As for which takes priority, Deny or Allow, usually deny does as I recall, no matter the OS. So again, working as intended.
As for the normal Security Settings for hosts, there shouldn't be any deny permission on it. If a user doesn't have read access to hosts, he can't use it at all, thus the file is unusable. The system shouldn't be adding the Deny by itself, thus someone added it. Either you did (in which case, your fault, but luckily, you are able to remove it), or a third-party program did.
Is the problem that Deny takes priority? Again, as I recall, that is the normal (or it may be the normal on the software I used so far). Is the problem of incorrectly set permissions? See who set them, since it wasn't MS.

tl;dr
Hosts shouldn't have any deny flag set, blame the one that set it, not MS.