As a professional sysadmin, I can add a couple more cases here:
d) When the user installs their own packages and it breaks, they still call me. I don't have any idea what they're doing and can't debug it. Yet all too often, the user views the brokenness as my fault and my responsibility (and yes, that includes escalating their problems up the management chain). Ergo, I'm not going to let said user cause problems for me in the first place.
e) All too often, the user does something very ill thought out and irresponsible with their own installs, such as using a HPC cluster to spam a corporate database not designed to handle that load or sending confidential data out with insufficient security and controls (we're subject to HIPAA and Sarbanes-Oxley, at a minimum). I find it necessary to insert myself into this process as a basic design check on what the user is doing.
It's the classic trade off between free innovation and rational controls. Yes, rational controls significantly slows down the process of free innovation, but recall that most new ideas don't actually work, something like 90% of new ideas and/or companies fail in a quite short amount of time, many of them dramatically.
For the "do whatever you want" systems, we give users heavily sandboxed cloud resources with a very explicit contract "you break it, you fix it, and IT security knocks on your door, not mine"; or we just send them out to amazon or similar.