It's part of a tester's job to ask questions about the product that nobody else has even thought of yet. Waiting until after significant programming time has been spent to even start asking those questions - well, does that sound sensible to you?
Some of my best defects (except we called them review comments) have been raised before a single line of code was written. When working in a waterfall environment, if a project came to us for testing where static testing of the requirements hadn't been conducted (or had been conducted poorly), we considered it high risk (as such projects normally overran horribly in cost and time - if they weren't cancelled first). When working in an Agile environment, I am expected to be able to ask questions that reveal scenarios that nobody else has thought of yet.
Yes, it does mean testers need analysis skills. But then, they aren't going to be able to design good tests if they don't have those skills. If they're merely designing confirmatory tests that just check the requirements are satisfied, rather than test them - then they're not doing testing, just checking.
The other part of it is that if you don't involve testers at the requirements stage, it means that they don't start building up their understanding of the problem space early, which threatens the value of their testing.
It is possible for a good tester to cope with stuff that just gets thrown over the wall - there are strategies to deal with that. But if you have a choice, then why wouldn't you want feedback earlier, rather than later?