Hairy code comes in all shapes and sizes. You can create hairy code with any design methodology that you follow. That's generally why as developers we pick methodologies that both make sense to us, make sense in our development environment and make sense for the language. As someone pointed out here: The design pattern I prefer isn't going to mean diddly squat in ASM, comment will likely rules there, even for the most simplest of statements.
I prefer to structure my code so it makes sense
I do too, I think everyone does. How we make our code readable depends on the design methodologies that you would pick.
I no more want to break up a "open the database" method of my database object into multiple methods
The problem with that being the rule rather than the exception means that you can have functions with hundreds or even thousands of lines.
break up my "database connection" class into a bunch of separate classes, one for each piece of functionality you might invoke.
Unless you were following a CQRS Design pattern (where even then you can minimize class counts) There is no reason to do that. As you said, classes handle state so you'd only break up a class if you wanted separation of state.
For me, although there are many factors I have when considering breaking up a function, I think the most extreme of them can be summed up with:
Your massive developer-grade display isn't big enough to display it: Actually, displays of today are big enough that a function that is anywhere close to its height is probably way too long. But, if it is larger, this is a smoking gun that something is wrong.