if developer spots that he can push some rarely used data to external storage he would be very much willing to do so. "Not so fast!" says the reality - "You need that data to compute hash".

You still have that data and you can still compute with it, you just access it in the external storage during the computation.

Since state is internal juice squeezed out of consensus, it shouldn't matter how it looks on the inside.

I think you've taken an overly broad view of what I mean by state in this case. I tried to clarify this slightly in my original post by noting "(or some portion of it)". One way to look at state is "all variables stored by the system (including potentially data on disk)", but another view is consensus state: the meaningful data that is computed from the blockchain data and provided to users.

For example, account balances are consensus state associated with many blockchains. The blockchain data only contains the funds transfers operations, and these transfer operations are used to compute the account balances. If they use different rules to compute these balances, then the nodes are operating under different rules. Knowing quickly about such differences in "balance state" is a useful thing, and not something that is provided by the 1st layer validation of transactions.

Regardless of how data is represented internally, all nodes should be able to compute hashes that agree about the account balance amounts (because it's a basic requirement of the software to be able to compute these balances, regardless of internal representation). In other words, the ability to compute a hash on consensus data that must be potentially provided to users imposes no real restriction on internal data representation.