I see most of your points, but I still use them..
Mostly I use regions during construction. I work on my code in categorized pieces. If I am building a MembershipProvider I will code fold away the done pieces so I can focus on the not done pieces saving me scroll time and keeping my brain on task. When It's done I remove them all and then I add regions to separate out the different types of code.
region Fields, region Properties, region Constructors, and region Methods. I always have mode code structured in that order, Fields at the top, then properties, then constructors, then methods. As such I like being able to collapse the fields and properties when I am adding constructors, or collapse the top 3 levels when I'm working on the methods.
For me it's all about making it easier for me to focus what I am working on while scrolling as little as possible, and not having to search for anything at all. The less time I spend scrolling and using Ctrl:F the more productive I am.
I like other developers to follow my lead on my team, because if Bob adds a Field, I know exactly where that field should be, right above the closing #region tag for the Fields section, because they are in order of "Date Created". Using this structure I can generally look at code someone else added on a later check in and I know what they added without having to look at the change log.
Nothing annoys me more than seeing a field declaration at the bottom of a class between a method and a property... It makes me cringe when all the fields aren't together, and all the properties aren't together, etc etc etc. The region pattern I use hints for people to put things in the write place in the code file. The right place being where everyone else on the team is putting things in the code file.
As such I find it greatly increases organization and team work on team based projects (multiple developers and source control.)
And VS 2013+ will expand code tags that contains the results of a search, and go to definition as well, both automatically unfold code.