Well, let me first say that nothing (except, perhaps, breathing) is objectively good under all use cases. Haskell is objectively good for the level of code quality that it makes possible, for the beauty of language, etc., but you wouldn't (to my knowledge) use it for a hard real-time problem with sub-millisecond latency deadlines. In terms of specific tools and languages, there are few things that are objectively good and bad in all circumstances. Even tools that I personally dislike exist for a reason, and it takes some work and insight to know what that reason is (and, then, gain a begrudging respect for the tool).
However, as I get older and observe (in part, by being part of it) software management, I realize that there's a lot of so-called "innovation" in the field that is objectively harmful and with absolutely no redeeming qualities: stack ranking, Scrum, the two-week "sprint" cycle, the idea that it's normal rather than dysfunctional for a team to spend 3-7 hours per week in status meetings, and the willingness of management to jerk people around from one project to another as if they were interchangeable parts, denying the average engineer the experience of actually ever finishing anything. This industry is in advanced catastrophic failure and someone needs to fucking step up and save it.
There are things that objectively suck and of which it is an objective fact that a person who supports them is either misled, stupid, or malevolent. At this point, I'm not talking about technologies because I would never, ever say (because it isn't true) that Java (as much as I dislike that language) is objectively bad for all use cases. For some use cases, it's the exact right tool. On the other hand, software management generates bad ideas by the truckload ("Agile" and Scrum being the current rash of stupidity, along with the open-plan fetishism and age discrimination coming out of the Valley right now) and someone needs to call that shit out because it's ruining a generation of software engineers.
I've come to the conclusion that Sturgeon's Law (90% of everything is crap) is often true, but that's OK so long as there's a filter that allows the other 10% to have disproportionate impact. I like Haskell because the compiler itself acts as a Sturgeon Filter. It beats on you until your program is, quite likely, not-crap. Software engineers, themselves, willingly run their work through Sturgeon Filters (compilers, test suites) all the time because the job requires a respect for how hard and detailed the work is, and an acceptance of one's own fallibility. Software management, on the other hand, has no Sturgeon Filter... because the appropriate filter would be the people being managed, who don't have the power to stand up and say, "All of this neo-Taylorist Scrum nonsense is less than worthless and everyone talented will be gone in 12 months if you actually try to Scrum-ify the whole company." The reason why software engineers have such a low respect for software management is that the latter never gets direct feedback when they fuck up. Programmers get called out by their subordinates (compilers) and like it that way. Managers are rarely directly told that stack-ranking and Scrum are horrible ideas that can kill a company within months.
On an aside, how did cynicism become a bad thing? For all the negativity attached to the word, its original definition was something related but fundamentally different. Originally, to be cynical meant to do the right thing in spite of a knowing detestation for human political machinations and moral weakness. Cynics valued simplicity, clarity of knowledge, a lack of personal shame, and reserved (but direct) compassionate action. How is that a bad thing?