You're right, of course. But it depends on how you draw the boundaries of the system. If you think of the numbers in your example as code, then the program is stateless, and each time you change a number you get a new program. But if you think of them as parameters that live outside the code, then the edit-recompute cycle is a state change. In a similar if trivial way, if you take (say) a Java program running over a database and decide that the data in the database is "code", that "program" (consisting of Java code plus database) is now "stateless" too, and anyone who updates a database record is changing the "program".

Given that "stateful" vs. "stateless" depends on how you draw the boundaries of the system, the question is how best to draw the boundaries of a spreadsheet. I'm not arguing there's a single correct way to do that, but in my view the user's mental model of a spreadsheet is closer to "a calculating machine with state that I can update" than it is to "a stateless calculating machine with a lot of hard-coded literals".

Psychologically, updating the numbers in a spreadsheet doesn't feel like editing the source code of a program and re-running it. It feels stateful, like mutating something that triggers a cascade of side effects (recalculation). For this reason I think that spreadsheets are closer to the Smalltalk vision of a world of objects that respond to user interaction (as well as to each other) than they are to the functional programming vision of pure code. Put differently, the spreadsheet's I/O, its grid UI, is part of its essence. You can't abstract away from that without losing the heart of the thing. So the analogy with functional programming, though tempting, leads in the wrong direction. Every individual formula that lives in a cell is certainly a functional program when taken in isolation—but the memory model by which the cells reference one another and get updated is stateful.