Coming from a fairly serve-centric background (CA coding, wiring together stuff on the server-side, etc.) I abhorred doing any "web-work" for a long time. It felt cheap and not particularly interesting. Not that I checked it out, though.
I knew it was cheap, because I didn't work with it. If it would have been worth a second glance, of course I would have done it years ago, right? Since i worked in the field I felt I had a fairly bulletproof opinion on just about anything connected to the server-side, even if I had no direct experience working with it.
It felt safe and reasonable to shoot down stuff based on general assumptions and theoretical arguments, rather than giving things a decent spin with a 2-5KLoC actual project, so that I would have an actual idea of what I was commenting on.
Sadly, it seems I'm not alone in this endeavor. I recently did an informal poll at a LinkedIn forum, asking how many people had ample experience with both PHP and Java (say, at least a major project in each - major as you will) - and I came up with a lot of comments, but no one actually having had the dual experience I asked for. There were the usual comments that reduced one or the other side to smithereens based upon no real evidence at all, of course.
I think the reason is that there are very few programmers that do cross-train. We have corporate agendas, certifications, gazillions of reasons to not rock the boat (and get back home in time to dinner - a whole bunch of things that make you code in just one language.
The problem is that the world of programming is in constant change. New ideas pop up all the time, and looking in the rear view mirror, not all languages or frameworks were completely spot on in their 1.0 revisions.
So it is fairly safe to assume that the state-of-the-art way of doing things four years ago (for instance) might not be the most cost-effective way of spending time coding.
To try to round off this post, I've learned the following things;
2) The more logic I put on the client side (The browser again, natch), the easier my server-side components gets to write and maintain.
4) The whole point of web frameworks is to generate the client out of the server, making the server very complex to wrote and maintain, despite or because of that the whole point of the web frameworks are to reduce that very complexity.
Also, when I try to discuss my findings with people, I get invariably into long discussion where otherwise very smart people try to argue that I am wrong based on theoretical arguments - not having had the experience themselves.
And what does that mean? It means that the status quo has to go. No Tapestry, no JSF, no Wicket, Struts, Ruby on Rails or Symfony. Nothing at all. You can see why this is so very popular to talk about :)
In the end it is all about money. How much does it cost your company to build, a system and how much does it cost to maintain.