I'm not against frameworks, in fact I'm all for a set of patterns and classes that make me more productive. The problem is that having too many choices, many of which are just variants of the same idea and several others just short lived experiments, don't show creativity but lack of leadership. Don't you see you're drowning programming teams in framework-choice paralysis?
Yeah. Agreed on what you outline as a lot of crap amongst those frameworks. But hey, it's open source, so your choice making process helped by a lot of transparency!
For all you people suffering from that modern world irritation with having too much choice (there's democracy, free trade, too many tv channels too) here's one way to select your frameworks:
1) Define an area where you have a problem or feel you can improve your development process. Don't fix a problem you don't have.
2) See what kind of frameworks you need based on 1), and decide - after a quick scan of the available frameworks - whether you want to go for all compassing frameworks or a combination of best of breed.
3) Use your favorite search engine to track down the most popular alternatives. If you came up with 50 *viable* alternatives, you are not a very efficient searcher and you will suffer from information overload paralysis within a few years. If you didn't you probably came up with less than ten as you just looked at the first two pages, and consulted some 'expert' sites or blogs for the popular choices.
4) Visit their websites, look at some idicators like how long they exist, mailing list activity, number of contributors and read some basic documentation to get a feeling for why the authors think their framework will help you.
5) Do a checkout of their code. Look at the quality of their code. See if there is sufficient testing code, look at the tests to see how things are done and whether corner cases you might expect are being tested. Besides giving you a good indication about the quality of the framework, it is just fun to look and learn from other people's code - at least when it is well written. And don't forget to check out any examples too.
6) Finally, pick your favorite two or three and, starting with your nbr one, create a simple prototype that displays just enough to 'prove' it will solve your problem.
x) If you didn't find any suitable framework, not to worry. At least you tried to prevent reinventing the wheel, and you probably got some inspiration on how you can start solving it yourself.
x) Don't adopt the decision making process of your manager. He has nothing else to do anyway, so he is specialized on formalizing his decisions based on common sense parameters (did anyone out here read freak economics?). You otoh have some code to write.
xx) Sometimes you make a bad choice. One of the hardest things to do is admit that and start over again. I am still sorry for the times I didn't and got stuck with a lousy framework.
So, yeah, it's some work. You spend a few days upfront for that multi-K project to select the best tools for the job. Of course, you don't *have* to do such a framework selection at the start of your project. Though I think it is a good idea for you and your boss, and personally I even like to go out and see what other people came up with :)