I would not say there is a definitive answer, rather it would depend on how you conducting the test and what type of data you are looking for.
Tasks vs. Scenario
Tasks would be quick and to the point, where participants don't necessarily need at background information. Having a series of very discrete tasks, with little to no relationship to each other, would allow of more immediate querying of where they "went wrong" after a task.
Scenarios provide rationale and context to the user, setting the stage for a story to be told. Asking the user to break out of the story to explain what "went wrong" could affect at least their immediate reactions to the next task in the scenario, as they work to get back into context.
As tasks can more easily be broken with immediate queries, a more scenario based test is what becomes more tricky...
Qualitative vs. Quantitative
What type of data are you looking for?
Success metrics for quantitative test data include the number of successful tasks completed and the number of successful/unsuccessful steps within a task. While to say the reason behind what "went wrong" in quantitative data "doesn't matter", its weight is diminished. If you are looking for strict quantitative metrics, breaking in to ask is less helpful.
Collection of qualitative data through observation and understanding includes multiple insights. Included is what problems where encountered - not knowing where to go, what to do next, finding what they were looking for, and could they recover from errors?
In qualitative data collection, asking where the user "went wrong" is much more important. But when?
Immediate vs. Post-Test
Once the facilitator has allowed the user to flounder for a bit, a period that is unique to each test, its time to get them back on track. When the user is guided back to the correct point the facilitator has the choice to immediately break in, or to let the user continue.
The facilitator can go through several attempts, asking the participant to "think aloud" to get an understanding of why they are missing the button. A good researcher might find more meaning in a participants verbal walkthrough, than if the participant is just asked "why did you not click that?" Participants might not be able to see exactly how they "went wrong" and may not be accurate about it (intentionally or unintentionally).
You've not outright asked the participant why they "went wrong", reducing the potential for "feeling stupid", but you can still pull out the information you were looking for.
Asking in a post-test situation, if you are seeking qualitative data, suffers from a participants potential inability to remember why. If the testing session is too long, and the "error" was early on, the user may not remember what happened. Additionally, their memory will be muddled if they had to be shown the button in order to reach a new task; they will likely remember being shown the button more than why they missed it.
If a post-test questionnaire is provided, it just makes sense to ask for an explanation of what "went wrong". But the answer needs to not be taken purely at face value.
Immediate Discovery AND Post Rationale
In the event the facilitator needs to "rescue" the participant, discovering what went wrong is more useful then asking what went wrong. Having the participant work through, and verbalize, their task flow demonstrates their mental model to the facilitator - who can then understand what "went wrong". Simply asking allows the participant to think about it, and change their answer.
Although subject to memory and ego, ask the participant for rationale after the test (or at logical break points within the test, such as between scenarios) for their take on the situation. Answers can still yield valuable insight into why the "correct" action was missed.