Yea I've heard the blub story told over many times.
I understand functional programming perfectly well. It's just that for most of the time, it's easier to think imperatively. Yes, there are some special problems (Towers of Hanoi, Ackermann's) where functional programming is truly the way to go. But in most cases it isn't.
FYI I use gotos in my C programs when I see it's the easiest & clearest to get something done. I think you should go with what best suits the situation.
What troubles me though is when you go out of your way to do everything functional-style, even when you know there are easier ways of doing it. And the problem is this happens way too often to be ignored. Some functional programmers just push the functional idiom into everything they do, to such a point that understanding their code is like solving a sudoku puzzle.
It's not about how easy something is to do. The greatest value of functional programming is robustness. In 10 years of professional programming, I'd estimate that something around 90% of the nastiest bugs I've discovered would have been preemptively prevented by using a strictly functional style. Sometimes these bugs are just the result of poor thinking, but often they are the subtle result of changes over time that would be almost impossible to anticipate.
Functional programming imposes some constraints that range from mild discipline to mind-bendingly difficult. However in general I can't think of many constraints that provide a better power-to-weight ratio (garbage collection is probably one).
If Haskell was the dominant language and functional programming was how everything was done all the time, then I could buy into the argument that there are easier ways to do things. However as it stands, not enough people really grok functional programming (myself included) to optimally apply those principles towards the creation of robust systems in non-pure languages.
I think you may have missed the point of the blub story, then.
> What troubles me though is when you go out of your way to do everything functional-style, even when you know there are easier ways of doing it.
The point is that you (to possibly generalize a bit since I don't know you) are 'going out of your way' to write everything in an imperative style because you don't know there are easier ways of doing it.
This is exactly what the blub story is saying. You are looking 'up' at functional languages and saying "in most cases that's just esoteric weirdness that I don't need" because you think in blub.
Here's an alternate version of your last sentence from a hypothetical functional programmers perspective:
> Some imperative programmers just push the idiom into everything they do, to such a point that understanding their code is like untangling spaghetti.