All programming philosophies are about state

I think what the article intended by “declarative” is roughly occupied by the “logic programming” paradigm and DSLs like SQL. If my intuition is right, they have a lot of conceptual overlap. But they differ mostly in how much they realize a goal of “what, not how”.

State is made of data. The difference is that state is data together with a persistent identity (morally, a location), and the data associated with that identity may change over time.

Turing Machines are defined in a way which makes a distinction between data and state - it consists of a state machine (which controls what happens when each symbol is read) and a tape (which records symbols - data - which will be manipulated). The state machine is part of the Turing Machine's definition - so one Turing Machine can only have one particular state machine configuration, but can operate on any tape with any content.

However, the existence of Universal Turing Machine (a Turing Machine that can simulate behavior of any other Turing Machine) demonstrates that data can also represent state - i.e. you can encode an arbitrary Turing Machine's state machine in the tape, without changing the Universal Turing Machine's state machine at all. That's how we got stored program computers.

In a more practical sense, a useful distinction between data and state is within the boundaries of the program - any data that is internal to your program can be considered state, while any data that you read from an external source/write to an external sink can be considered just plain data. Separating the two is a helpful technique in writing reliable software.

we must build a Functional Economy.

Is this another way of putting what you're saying?

In functional programming, we think of computation as reducing an expression; a computation is complete when it can't be reduced anymore. In imperative programming, we think of computation as updating a store of data; a computation is complete when we run out of steps to perform.

When you're partway through execution, the "rest of the program" in an imperative system is captured by the current state of the store (including the stack). In a functional program, the "rest of the program" is just the program expression itself, reduced as it has been up to this point.

I tend to like the functional model, myself, but I can see the mental appeal of keeping the program text fixed, and isolating all changes to a separate store of data.