Regions were a mistake and they cause far more problems than they solve.

I started a new job a while back and one of the existing devs was showing me the code that runs a critical part of the system. I'd previously noted that the function in question was about 1000 lines of heavily copy-pasted code (e.g. if they had a switch/case, each case might be 20 lines long, the same 20 lines, but with a tiny modification in each case--it's like they'd never heard of functions--or more correctly, they knew their class had to do things in a function, but never thought to break that function down...) I watched him click through it and it was obvious why it had grown so horribly out of shape. Everyone used code folding, and just expanded/collapsed each region they were working in, so they never saw the whole terrible thing at once.

Same company has colossal kitchen-sink classes all over the place that suffer from the same problem, as you might expect. SOLID principles thrown out the window. Region abuse is definitely part of their problem.

There is absolutely no excuse for it. You're not meant to make multi-kiloline classes chaps. This has been common knowledge forever. If you really really must make a class KitchenSink then I expect to see files for class Tap class Drain class Plug class SoapyWater and KitchenSink can just compose itself out of them. I don't want to see one big KitchenSink.cs with named regions where you should have classes.

Anyway this time next year their codebase will be a sparkly, beautiful thing with actual unit tests and a completely turned-around dev culture or I will have failed...

I think banning regions that contain a nonzero number of lines of procedural code would be a nice start.