A superb answer does not make a bad question into a good one. That's not what we really have here though.
What we really have here is a question that's much more focused and constructive than you realized. You initially perceived it as overly broad, and probably not constructive. That's simply a mistake on your part though. In reality, the question is fairly well focused and a good answer to it provides useful information.
IMO, much of what we have here is a bias (probably selection bias more than almost anything else) that (for one example) almost automatically assumes that virtually all optimization is really premature optimization. I believe this stems (at least primarily) from two points: most programmers write applications that have only fairly minimal performance demands.
I've long-since lost count of the number of times I've seen comments suggesting (possibly indirectly) that unless you've profiled code and found its performance problematic for your specific application, that you shouldn't care about optimization. While I certainly favor profiling (of code, anyway) this largely betrays an application-bias. If (for example) you're writing code for an operating system, compiler code generator, or library, your job isn't to ensure adequate performance of one application -- it's to ensure adequate performance for many applications (including those that haven't been written yet). Much like debugging can show the presence of bugs, but not their absence, profiling can show the presence of performance problems, but not their absence.
Likewise, some people routinely work in domains where performance really matters -- they can't afford to profile and optimize only the worst problem areas. They need to improve performance as much as possible everywhere to have even the slightest hope of a usable result1.
Even for those who don't truly need maximum performance, achieving it is often much more useful than most people realize (or are willing to believe). Many people prefer applications that feel "quick" or "snappy", even when/if they're not really necessary. Programmers (good ones, anyway) rarely write code to just meet the minimum requirements and move on. Code can be (and I will posit, should be) aesthetically pleasing -- and that should extend not only to the UI, but to the internal structure and yes, also to performance. Performance should be balanced with other goals -- not ignored.
The same background of many users on SO leads to another type of bias: the idea that "good" questions should usually admit to simple, concise answers. To an extent, this isn't unique to SO either -- the popularity of Twitter (for one example) shows the degree to which short, simple messages are (currently) perceived as good. While this is certainly true in some cases, it's not in others. It's also true that some questions (no matter how "good" they might be) require a longer answer than is reasonable to post on SO. Nonetheless, it appears to me that many have formed a somewhat warped sense of the reasonable limit on the length of an answer on SO (or at least the length that should be needed).
Ultimately, votes (up, down, or to close) on a question should be based on the question itself. That does not necessarily mean "the question in isolation" though -- when you see a great answer to a lousy question, that should make you stop and think a bit. Yes, that might really be correct, and the question really is lousy. There is another possibility though: when the answer is great and it really addresses the question (not just a great monologue prompted by, but not really responsive or related to the question) chances are that your perception of the question as lousy was mistaken.
That's the case here: the question isn't perfect by any means, and narrowing it somewhat would certainly be an improvement. Nonetheless, much (most?) of the negative perception stems more from bias on the part of the readers than from real shortcomings in the question itself.
- Yes, there are undoubtedly many times more who think they're in this situation than who really are -- that doesn't mean there are none who really are, nor does it mean we should automatically assume everybody is wrong when they think they are.