To be fair, that hasn't happened in a pretty long time for me - but in the earlier days it was commonplace. It used to be bleeding edge features that would do it, other times it was just because they took so long, that interrupting the process of upgrading or installing caused a mess. Or installing the newest version alongside the older version, etc.
Visual Studio is a massive and complex creature (much like other "big IDEs", such as Eclipse) - although it has become much more streamlined in more recent releases - considering how complex it is.
EDIT: To be clear, problems often involved corruption of registry values, library/DLL hell, small database or configuration files and caches, etc. that happened with Visual Studio in the scenarios above.
Yes, since the inception of these kinds of tools, recovery from these corruptions became easier by restoring from an image. Still, in the early days, you could burn a lot of time doing anything of these things!
Sure, sometimes installing new versions alongside old versions could cause issues. But that's a managed process that one team member would do before the whole team migrated and any issues would be worked out during that stage. (one of our old upgrade steps was to install 2015 before 2013 because doing it the other way around would break something in 2013; 2013 still being needed for some projects).
I have never been in the situation where the entire company (or even entire team) was locked out of their IDE.
Also, while this isn't bricking the IDE, you can definitely ruin solutions & project files in a very hard to debug way if you ever need to manually update those files.
Restores operating system image in a few minutes.
Visual Studio major version updates (uninstall old plus install new) used to be a good way to do that and often wreak havoc on the overall stability of your system as well. At least, on a system where you didn't want to strip it to fresh OS install as an intermediate step.