I also agree with your sentiment. Excel is coding for people who are not programmers.

But I think the author conflates 1) engineering practices

2) Programming

3) Expressing domain knowledge using tables, charts and numbers

Most excel users do 3) They are certainly not programmers, and the do not follow engineering practices we associated with programming: modularity, hiearchical or functional re-usability, testability, etc

Excel creators do not reproduce bug reports, do not measure their success by the number of bugs they fixed, they do not do SDLC...

These are not particularly fault of excel. But as soon as there is a recognition that 'oh that excel workbook needs to be managed by programmers' -- then after a few month programmers realize that Excel and VBA macros are subpar programming environment, and will just argue that the way that the author does -- that it does not make sense to maintain a complex, business critical code within Excel.

So they will re-write it in Python or something else.

---

I think Ex cell's success in the business world is precisely because it allows non-programmers to bypass the whole SDLC and express their domain knowledge in a computational system.

As programmers, we want to replace Excel with something that

a) allows business users to do what they want to do, without SDLC

b) when their work reaches a certain level of complexity, we want the tool to allow us to gradually transition the work the domain users have done into an engineered piece of software with minimal effort, free of cost, easy to debug.

I do not think such as system exists yet, but that would be a killer app