|I worked at Rational for years before and just after they were bought out by IBM.
The situation is even worse than both you suggest, though you hit many of the problems.
ClearCase also maintains client enlistment state information on both the Server AND the Client.
*AND* both sets of data have to both exist and agree, or the clients' enlistment becomes unusable without admininstrator intervention.
It was not uncommon for the client-side file turds that store the Client-side Client state information to become corrupted (HDD dropout or failure, BSOD, etc), and thereafter have the client be unusable until things were patched up.
After a while I personally got in the habit of routinely using a CMD + Perl script to detect files that were changed in my enlistment(s) and squirrel them away somewhere.
That way, when ClearCase quit working on my machine because one of the file turds got wacked or wacky and if the administrators' were not available or unresponsive, I could at least recover my state by creating a new enlistment and starting over.
Well, even that was not always possible, not before the original client was recovered or deleted.
But at least I *could* recover.
However, doesn't all that sort of negate the reason for having SCC in the first place? If users have to squirrel away private copies of their code to protect it from the SCC system itself AND often work outside of or around the SCC system in order to get their work done, what's the point???
FWIW and as an employee of Rational we used to routinely file bug reports and usability dings etc against ClearCase, but all that did is incur the wrath of management who believed the boneheads who owned ClearCase when they said we were just whiners and weren't qualified to pass judgement on an enterprise-capable SCC system.