To some extent I agree with you - very few non-trivial applications are easier/better in procedural vs OO (and I agree with you on the functional approach too - but just try writting a useful Haskell version of a nontrivial app - sheesh!!). It just depends on how wide your values for non-trivial are :-)
I find I use procedural approach heavily in the startup of an app development, and once that is humming, focus on the OO from then on. E.g. I usually focus procedurally during the startup of my app on

• reading parameters (using Getopt::Long exclusively)
• setting up logging (using Log::Log4perl exclusively)
• setting up filehandles (using IO::File exclusively)
• setting up timing/stats
• when required, setting up DBI (using DBI)

after that I start doing the decomposition dance
oh, and btw, I make it a rule never to write the same code twice in an app - I always factor out to a sub or method. This help highlight new candidates for classes/modules faster. And if I notice that much of the code is avariation on a theme, I stop and try to find some abstraction that allows me to parametize that code.
I think it was Donald Knuth who said
Every problem in computer science can be solved with either more - or less - abstraction. Experience tells you which one of those to apply.