We used SCCS on a shared filesystem. If you really needed to edit a file somebody else had locked, you simply removed the lock file. Of course, social convention was that you better have a really good reason for doing that. If you went on vacation with files locked, it was pretty much expected that your locks would be removed, and that you'd have to merge or otherwise deal with your stranded edits.
That's common amongst the older breed of VCS: VSS or Perforce do the same.
It's useful when working on binary files which can't be merged. Some centralised VCS (e.g. SVN) can be opted into locked checkout on a per-file basis.
Definitely not a great default though.
I've worked with both SCCS, RCS, Perforce and git. The way SCCS and RCS did it was a pain, but Perforce's was IMO more feature than bug. When Perforce told me "uh, X is editing this file you're just about to edit", talking to X was usually a good idea for some reason I wasn't aware of. Sometimes X was working on one issue and I on another, and the deeper cause was actually the same. Sometimes X had forgotten to check in some work and would do so immediately when I asked.
Not always. But often enough that I liked those locks. (Hated the RCS/SCCS locks though. Those had far too much cost and offered too little value.)
If you're doing critical heavy lifting or refactoring, merging inline changes is hell.
I think the informal technique works better since it’s a lot more flexible, but the basic concept is very useful.
For Perforce, that is false.
For Visual SourceSafe, that behavior is the default, but can be changed.