I completely agree, but since it would take an incredibly larger amount of effort on the dev's part to generate a) what should be a privilege, b) what the requirements for gaining access to the privilege are c) what should cause the privilege to be revoked, and d) actually monitor those systems, there's no way they'll actually do it.
Throwing gigantic rules blankets over the whole population is so, so much easier.I don't agree. Sure, having one simple rule for the entire population might be easier. But that rule doesn't stay simple for long. It gets hedged about with exceptions and special cases. And that makes the whole system more brittle and prone to unexpected error.
From a programmatic standpoint, privileges or permissions are not that hard to implement. It is simply a different way of looking at the problem.
In fact, it is a very common technique in operating systems or business software. Can you read, change or delete a file on your computer? Rather than trying to apply a single rules heuristic, it's just handled by the permissions on that file. The OS doesn't really care how you got those permissions, but only that you either have permission or you don't.
Business software and operating systems have a mental conception of users that fit into different groups, which is why privileges feel natural to them. It is only gaming software that tries to pretend that all its users are the same.
As well, permissions don't have to be calculated in real time. The game generates logs, and those logs can be parsed at a later date by bots looking for patterns. Indeed, if you come up with a new and better pattern recognition bot, you can rerun it on old records. A simple example might be a bot that looks for people who swear in public channels. All chat logs are saved, so a bot can traverse those records at its leisure, spit out results, and those results can set chat permissions which apply in the future.
But you yourself just laid out a number of what you consider the perfect cases for it being a privilege that cannot be strictly programmed in; else you get systems like we already have!
Example: If you designed a new game that had a vote-kick system, what would your programmatic patterns of abuse be? The guy kicks a lot of people? How does the program know that it's not legit?
Example: If a person is needing a lot on gear that's actually wearable by them and offered to him by the game, how do you know he's not just making a legitimate use of the game system?
Here's the thing. I believe that abusers of rules exhibit very different patterns of behavior than regular users. Take vote-kick for example. I almost never vote-kick anyone, and I pretty much only run LFR/LFD at this point. I just don't see that anyone can possibly justify a high vote-kick rate in dungeons. I think the problem more likely lies with the vote-kicker.
Same with Need/Greed. Alright, maybe in your first instance run, you have a higher than average amount of need rolls. But if you keep that up, that's a clear sign that you are behaving badly.
These patterns should be identifiable. Obviously, you do need some history, to let the Law of Large Numbers start to kick in. But if you were presented with a player's history, I think it would not be hard for you to determine if a player is exploiting the rules or not. And if you can see the pattern, then a bot can be built or trained to see the same pattern.
Take a player in a battleground. If you look at the players's history, and see one battleground with zero damage or healing, well, maybe he was defending a node which never got attacked. But you start seeing more and more of them, the odds that this player afks or is a bot increases dramatically.