Lest people see this post and think the expressed opinions are a universal consensus of this site's users, I wanted to provide a dissenting opinion.
Software engineering is a challenging field, and people have questions at all levels of abstraction of the design process. A good answer writer adjusts to the level of confusion of the person asking the question, instead of expecting the question to adjust to the kind of answers that are easier or more fun to write. Good answers can and are made to the above-mentioned types of questions, in the short space before other people vote them as "too broad to possibly answer."
This site is supposed to be much more about general principles rather than specific applications like StackOverflow. We don't go around telling college students, "Well, I could teach you about when to choose insertion sort, but I don't know what your project would use it for." It's okay to be a little abstract here. Programmers are allegedly good at abstraction.
While I object to the leading and stereotyped wording of the example questions, I think they are in general a reasonable fit for a site that purports to be about "software development methods, practices, requirements, architecture, and design."
- "Review My Design". Design is right in the site tour. It's one of the main purposes of the site. People don't always know they best criteria by which to evaluate a design. If they did, most of the time they wouldn't need to ask the question. If they don't provide criteria, answer writers should list their own criteria, and state under which circumstances they would or would not be applicable. Most software design principles are not hugely situation specific. If you think you need context to answer, just say why the context matters.
- "What is the Best Practice?" Again, practices are right in our tour. A practice is not usually best under all circumstances, but it is not that hard to state the limitations. We don't need one-word definitive answers. If the answer is "it depends," tell me what it depends on.
- "Will my approach work? Is it viable?" Again fits under design. If you can't tell if it is viable from the question, state what information you would need to gather. State some alternatives that might be better. The question isn't asking for a contractual sign-off. It's asking for a second opinion about if anything major was missed.
- "Is this the correct/preferred/canonical/idiomatic/accepted/most popular way?" Sort of the same as the best practice question. Software is written for other humans to read. Part of that is writing it in the way other humans would most likely expect. The best way to find out what other humans expect our code to look like is to ask them.
- "Tell me all of the things that can possibly go wrong." Software is full of non-obvious gotchas, things that look correct but aren't. Asking someone with experience in that area to help avoid the worst problems is one of the most important reasons for asking questions. It's the main thing I wish my coworkers would do more frequently. I'll take someone any day who is paranoid about pitfalls over someone who constantly overlooks problems like concurrency or scale.
- "Tell me the name of this thing so that I can Google it." Every one of us had to learn the name of something at some point. Don't be a gatekeeper to knowledge. Be a facilitator.
Don't get me wrong, I have no illusions of actually changing the minds of those who control what questions get closed around here. I'm fully aware of your objections, so you needn't leave them in the comments. This answer was not written for you.
If your question was closed and linked here, know that at least one high-rep user has your back and is trying to change things.