MATLAB has some significant benefits over the FOSS alternatives, such as its first-party commercially-supported extensions/libraries (known as "Toolboxes"), and commercial support for the core product itself.
But outside of academia, let's face it, the most widespread "engineering IDE" is Excel. Relatively few engineers continue to use math and equations after they graduate. A lot of their calculations can be done in Excel, or within their CAD software. The biggest threat to Matlab is the automation of engineering calculations.
As a result, it's more mixed, with the people who are actually doing quantitative work coming from a variety of fields including math and physics, but also from areas that have no prior loyalty to Matlab such as biology and statistics.
For instance in my department, any deeply quantitative work is done by a very small handful of "math people" who may or may not have "engineer" job titles, but whose degrees are in math or the physical sciences.
I believe there are two reasons: 1. the popularity of Python for ML in particular, many students want to learn general skills that are relevant beyond a narrow "engineering domain". 2. Somewhat surprisingly a push from industry, where licences make up a significant chunk of the budget. I know several R&D engineers who switched over to Python, because they got annoyed that licences where not available when they wanted to work. This has changed the overall perception of Python in these companies (who previously regarded Python as a "hobby" project).
Regarding the toolboxes, in my experience quite a few are of extremely poor quality despite significant costs. To give you one example, the instrumentation toolbox is so buggy, that we essentially have to open and close instruments every time we want to send commands (otherwise we would get random freezes which often could only be fixed with a complete computer restart). This adds significant time, when we moved from matlab to python for our instrument control measurement time for a single measurement (of which we would often need >100 in one experiment) went from >5min to less than 30s.
I'm aware there are existing tools that see heavy use but that does not make them state of the art or cutting edge, merely sufficient. And yes, that can be enough. But for new work? Why throw in behind these guys?
spoken, truly, like someone that has never worked in a [^software] engineering firm. civil/electrical/chemical engineering firms all uniformly rely on matlab, comsol, solidworks, autocad, etc.
