To apply known methods in cases where they mostly work, you don't need to know the math behind them, you just need to know basic stats and basic probability to interpret the results. So if the assumption is that you'll simply be solving your problems by applying the known methods using the (great!) tooling made by others, then you don't need the math background; you can certainly train undergrads to solve quite nifty problems with the powerful tools without going into much if any detail about the underlying math, treating it as an engineering problem of following best practices. After all, the choice of e.g. a particular gradient descent optimization algorithm is not based on their mathematical properties (the proven bounds are so far away from practical results, and a better proven bound doesn't correlate that much with having better results) but on empirical evaluation, and in most cases you're not going to implement any of the low-level structures/formulas on your own anyway, in practical solution development you're just going to choose them from a list by name in the framework of your choice.
On the other hand, if the assumption is that your particular problem is not solvable easily and reliably with the current approaches, then quite a lot of the math background helps - if you want to improve on the current results, or debug/understand why your solution doesn't work as intended, or why the conceptual solution can't work on your problem because of incompatible assumptions, then these areas of math are useful. If you want to use a new bleeding-edge construct, or a rare niche construct that's not yet implemented in the framework of your choice, then you're going to need to write it yourself, and then you need to understand how it works.
There's a large distance between using and applying ML techniques and researching and improving ML techniques; it's a continuum, but there's space for many people standing purely in the applied end.
I think it's more nuanced. On average the better grasp of the theory an engineer has, the more pathways to success they have. Making better decisions, less guessing, leading a team, wanting to have input into future products and services, and so on.
Just having things be less opaque reduces cognitive load, makes more room for creative solutions.
On the other hand, if the assumption is that your particular problem is not solvable easily and reliably with the current approaches, then quite a lot of the math background helps - if you want to improve on the current results, or debug/understand why your solution doesn't work as intended, or why the conceptual solution can't work on your problem because of incompatible assumptions, then these areas of math are useful. If you want to use a new bleeding-edge construct, or a rare niche construct that's not yet implemented in the framework of your choice, then you're going to need to write it yourself, and then you need to understand how it works.
There's a large distance between using and applying ML techniques and researching and improving ML techniques; it's a continuum, but there's space for many people standing purely in the applied end.