I think I pretty much said the same thing in the first sentence. If you're just going to be a code monkey, then strong algorithmic skills probably aren't that important. If you're working on something like compilers, operating systems, data mining, parallel programming, pattern analysis, anything mathy, etc, your algorithmic skills and familiarity with data structures is going to make or break the interview.
And I agree, but at the same time the majority of developers probably aren't working on those, at least, not right off the bat (and by 'operating systems', I'm assuming you mean the deep kernel stuff, not, say, the shutdown menu).
I call BS on the "simple algorithm" statement. Naive algorithms are often disgustingly worse than cleverer solutions. This is true even in obscure problems that probably haven't manifested themselves enough to be written about. If you're working with small samples, then it clearly doesn't matter. However, when you're working with huge datasets (and there are plenty of jobs where this is the case), it's obvious that implementing naive algorithm after naive algorithm is going to produce a really crappy, slow product.
And I call shenanigans on you!
In all my years of programming, I've never had to write a "clever algorithm", except for schoolwork. I'm not saying that you never use them, for example in the cases you mentioned at the top, but those definitely aren't the norm anywhere. Another place they're useful is in a GIS solution (since I'm working with one of those at the moment, it's ont he top of my mind). But yeah, certainly not common in general.
Also, in terms of making a crappy/slow product, their interviewing obviously isn't working
This is an aside, but: I enjoy finding algorithms for tough problems much more than implementing solutions.
Nerd!