I work at an engineering firm (not software), and for performing and presenting manual calculations it it great. You wouldn't write a Python or Julia script or use a Jupyter notebook for any of it. Because I like to code, I've written small programs for more involved calculations in J, C, F#, and my favorite Frink. Frink is great for engineering because it handles different units and systems throughout a calculation. Mathcad is also good for laying out manual calculations. Excel is the engineer's scratchpad. There are just certain things that are just easier to do in Excel, and not everything turns into a problem that needs a programming language. But there are ways of working with Excel from most programming languages aside from VBA.

Given the problems with statistical functions in Excel, perhaps we should be a tad worried?

A lot of Excel's issues are well-known because of how pervasive it is. Python and kin rely on C libraries and other layers of imported packages for numerical work that can lead to all sorts of numerical mischief. Even doing:

  round (2.575, 2)

in Python leads to 2.57 instead of rounding up to 2.58. Everything in our engineering firm is checked by another engineer.

    In [7]: round(2.575, 2)
    Out[7]: 2.58

Umm?

From the Python 3.7 docs (https://docs.python.org/3/library/functions.html#round):

The behavior of round() for floats can be surprising: for example, round(2.675, 2) gives 2.67 instead of the expected 2.68. This is not a bug: it’s a result of the fact that most decimal fractions can’t be represented exactly as a float.

Well that is just normal float fun :)

    In [17]: Decimal(2.675)
    Out[17]: Decimal('2.67499999999999982236431605997495353221893310546875')

So sort of round() is working as expected, but the number you are not inputting is not the one you are expecting.

For a lot of things I'm a tad worried by an over reliance on statistical functions. ;-)