I guess nobody ever thinks of Excel in these cases? I've heard it's used sometimes for calculations. It doesn't need to do destructive updates to intermediate values.

I think the argument would be that, though Excel is awesome for small data sets and so validates that it is indeed a great way to think about things at a level, it does not scale well. Indeed, one of the first things people suggest is to run away from large scale solutions that were done in a spreadsheet.

Excel strengths come from the fact that the main mode of operation is generally declarative.

Excel's weaknesses for use in large scale systems largely come from the fact that it isn't easily maintainable because, in the same main mode of operation, the actual code is hidden in cells that need to be accessed individually (in terms of usability for someone trying to maintain it, its almost like having one line of code per source file, since you have to open each cell to bring the code in it into the "editor".)

The most common way to circumvent the problem posed by the second feature in Excel is to resort to coding in an imperative language, which negates the benefit of the first.

FP languages share the first feature, but not the second.

I would argue that Excel's sole strength is that it directly features the data to the user. It is not that things are declarative that is nice, it is that the data is all you see. Because that is all a lot of folks care about.

Indeed, the way in which many people populate spreadsheets is far from the functional way. It is typically much more imperative. They literally have a list of commands from someone for how to make the chart or tabulation they are interested in seeing appear.

The fact that spreadsheet regular users are programmed by spreadsheet power users (the ones building charts, formulas, etc.) in an imperative way does not mean that the creation of the spreadsheet by the power user is not declarative, and is really completely irrelevant to what is being discussed.