This principle has a number of different possible interpretations. The one that first came to mind was the artistic tenet of minimalism: “Less is more”. But I think that a better example for business the Law of Diminishing Returns, such as the extra test that satisifies a managerial target for “test coverage” but actually adds nothing to the value of the tests done.
In any case, managerial metrics such as “test coverage” are merely statistical constructs, and have little or no bearing on how effective the testing has actually been.
On reflection, though, I think this can be read as applying far more to risk analysis. What are the most important functions of the app? Which ones would cause the most trouble if they didn’t work? (Do not overlook the impact of minor but highly visible bugs. Reputational damage is still damage.) How much time is available for testing, and which functionalities of the app have to be tested before that deadline? Is that deadline an internal one – a milestone that must be passed, but where some presentational aspects can be deferred because the app isn’t going to be seen in public – or is it a stakeholder or public demo, or a release, where functionalities have to be in place because they have been in some way promised, or where there are stakeholder or customer expectations?
Business managers should be taking these things into account when allocating test resources to a project. Their appreciation of the nature of risk to the business should, we assume, be all the greater because of their outward-facing focus. They should understand the benefit to be gained from deploying testing resources and balance the loss to the company (through overheads) of providing that resource against the gain of not having to do rework, rectification or just plain fire-fighting.
Weighing these things properly in the balance, I think, meets Musashi’s idea of “gain and loss in worldly matters”.