Plus you're now burying how long your class is and the individual methods within. So a class or method that would otherwise be inappropriately long now looks a reasonable length.
If you feel like the code is so long that it needs regions, then refactor the code, don't hide the mess under the bed.
If I end up needing to go through legacy code, and there are a lot of gnarly, long methods/blocks, I'll usually add comments and regions to it as I go along. I'll use comments if I just want to note something, and a region if I want to note something about a region of code. It's my rough map. Being able to tell Visual Studio to arbitrarily collapse an area is handy for sketching it. The long term goal is to refactor, but it's handy as a way to quickly outline things.
I find regions to be useful 1% of the time, simply pointless 10% of the time, and hiding crappy code the other 89% of the time. When I open up code and see a bunch of regions, I immediately assume that the file contains way too much unrelated functionality and that the code is poorly written. This assumption is very rarely wrong.
ca82a6d - kenjackson - 10 files changed, 34 insertions: "Added some regions"
085bb3b - dpark - 10 files changed, 34 deletions: "Removed regions"
a11bef0 - kenjackson - 10 files changed, 34 insertions: "Added some regions"
2432f8e - dpark - 10 files changed, 34 deletions: "Removed regions"
cbe6306 - kenjackson - 10 files changed, 34 insertions: "Added some regions"
e7e1bef - dpark - 10 files changed, 34 deletions: "Removed regions"
....
I'm not sure how regions change how you create your class hierarchies and such. One of the first things I do when I inherit a project, is I add regions to it. I'm not changing the class hierarchies, but I am making it a lot easier to navigate within Visual Studio.