(Rather than keep a long initial post, I'm moving my list to a separate comment here.)
1. Lack of revision control.
I've seen this too many times. Someone messes with a file without even using a rudimentary revision control mechanism like RCS, then something goes wrong and no one knows why. What should require a simple "revert" suddenly takes hours to recover from. What should be obvious from a "diff" is instead limited by the accuracy of someone's memory. The sheer number of tools available for this is astounding, and the fact that many are free and simple to use makes it inexcusable to just "wing it".
2. Not using "sudo".
The worst offenders I've seen just give "root" to everyone imaginable, who then use it all the time (often from a "#" shell that's been open for ages, in which they run all manner of random commands without paying close attention). I once saw someone use "rm -rf" as root to delete a single symbolic link; I was cringing, hoping they would not type a space in the wrong place.
The "sudo" mechanism is a great friend to administrators. It forces a team to clearly acknowledge what privileges are required to achieve objectives, and it protects fallible humans from themselves.
3. Not using "visudo" and other helper tools.
I've actually been in situations where I was not the sysadmin, but had to clue in a sysadmin that "visudo" existed. I'd asked for changes to the "sudo" configuration that was used by some Very Important Scripts by Many Many People. Sure enough, the person made a syntax error in the file, which was promptly mirrored to a network of machines; this caused every single script to fail for some time. Had "visudo" been used, nothing would have gone wrong.
There are entire classes of errors like this that really are 100% avoidable: as long as you use the correct tools, nothing ever goes wrong. Administrators should be well aware of these.
4. Constantly messing with the core OS.
When did people decide that it was OK to be adding to or overwriting what's in /usr/bin and /usr/lib? The whole idea is that you do your meddling in /usr/local, or /somewhere/else/entirely, and leave the rest of /usr alone. This makes it clear if a problem is in the vendor's supported code or not, it simplifies OS upgrades and reversions, and nothing is ever damaged accidentally. I strongly recommend that Unix people read http://www.pathname.com/fhs/ in its entirety.
5. Being change-adverse.
I am routinely frustrated by administrators who become paralyzed, unwilling to change anything except on a ridiculously-long-term schedule. What's worse, they then decide to change everything that needs changing at the same time. Ironically, what some see as avoiding disaster is actually a recipe for it; something breaks, and one now has to debug one of 45 possible causes instead of one.
An isolated environment for testing is essential (at least, to the extent that's feasible with available hardware money). Rolling out changes should be something that's easily done with confidence, due to positive experiences on a test platform. But too often, change becomes a source of paranoia and CYA instead of being a positive and regular way to boost productivity in an organization.