WIFO is really more about risk management than it is about quality management. Depending on your risk model, WIFO may or may not be a good choice.
The first thing you need to do is define "worst" for your use case. Worst doesn't inherently mean something with a high defect or failure rate (although it may); it could also be a measure of complexity, cost, scope, level of effort, or uncertainty. In other words, "worst" is generally about how your project defines and estimates its risks.
Benefits of "Worst First"
The potential benefit of working "bad" sub-projects or dependencies first is that you may reduce the cone of uncertainty for the remainder of the project. Once the hard-to-estimate or difficult-to-complete stuff is out of the way, the assumption is that there will be less variance in other aspects such as scheduling or resource requirements because the remaining tasks are better scoped and the risks well-understood.
Basically, WIFO front-loads your risk. By placing riskier elements at the front of the project when you have the most slack, budget, and resources to allocate to any issues, you may be in a better position to mitigate those risks than you would be at the trailing end of a project.
Projects that wait until the end of the project to handle "big balls of mud" like complex integration tasks are at much higher risk of failure and forced death-marches than projects that have tighter risk controls. When used judiciously, WIFO can be one effective risk control among many.
Pitfalls of "Worst First"
WIFO is intended as a risk-control measure, and doesn't focus on delivered value. If you are working on a project where earned value or modular feature delivery is important, WIFO may be a poor tool.
Remember, WIFO front-loads your risk. If your goal is to fail early, this can be a good thing, and often represents a huge cost-savings over projects that fail late in their cycles. However, depending on why the work is considered worst, placing it too early in the schedule can skew a project by introducing premature architectural, design, or engineering decisions that would have been more self-evident later on. Lean methodologies advocate reserving major structural decisions until the last responsible moment, while WIFO often forces these complex decisions to be made much earlier.
In addition, since WIFO front-loads tasks with a great deal of uncertainty, improper use of WIFO can lead to sunk costs for the project. If the front-loaded tasks consume an excess of time or budget, your project may find itself behind the curve with no incremental value to deliver. And, as previously mentioned, premature decisions about design and architecture can lead to sunk costs in labor, equipment, or product design/implementation that can be very difficult to recover from.