You're welcome, but I'm happy to at least elaborate on why that answer was a poor fit for us:
- It presumed that the existing spreadsheet would be flawless and bug-free. That is almost never the case; ad-hoc spreadsheets are often riddled with mistakes.
- It presumed that it would be a high risk/expensive task to replicate that spreadsheet in a technology that was more suitable for the job. Yet (if you assume that the spreadsheet was essentially correct in its function) it is one of the simplest implementations - you have a working specification for the behaviour you're implementing. If you are not confident in your ability to replicate a working spreadsheet, and then test that your new code behaves identically, then what are you going to be confident to build?
- It presumed that the technology used to automate the spreadsheet would replicate its behaviour faithfully. But that's only true if you use the same underlying application, so you'd only get the benefits if you automated Excel. If you used Open/LibreOffice, or Apache POI, or something similar then you still have all the risks that come with a reimplementation.
- It failed to account for the operational complexity of such a solution. Automating a spreadsheet is fragile. The resulting system would likely be a nightmare to operate.
- It failed to account for the long term maintenance cost of running a suite of business applications that are cobbled together from bits-and-pieces without any planning or cohesion. In that environment you should assume that an application will be in service for 7-10 years with the possibility of it running for 20 or more years. One of the biggest ongoing costs for that team was the number of bespoke applications we had, each using esoteric technologies and inconsistent design approaches. For example, a project to upgrade the underlying Operating System (or web browser, or database, or ...) would need to test each of those apps and potentially fix bugs. Which meant finding the source code, working out how to build it and package it, etc. Not to mention the cost of trying to stay on top of security patches for the underlying components and libraries. Consistency has massive value in that sort of environment.
You learn those lessons from experience - if your experience has been in a similar sort of working environment. I don't presume that every senior engineer has that same set of experiences and will agree on the same set of priorities and tradeoffs. But if I'm hiring you and paying a senior engineer salary because you have experience, then it needs to be experience that is applicable to the sorts of problems we face and the decisions we need to make.
