My preferred term for this type of logic is "derived state" (or derivable). I see @smooth calls it "embedded" which I think is also a fair term, but I still prefer derivable -- because you have to derive the state first to understand what state is embedded.

"Soft Consensus" is such a poor choice for this, because it is not consensus related at all. This word should really be isolated from the idea. Consensus is only useful to determine ordering on actions, and this is done at the base layer.

In the case of a 2nd layer solution, you base on the assumption that you already have consensus on ordering. With this as a prerequisite, deriving ones desired state becomes deterministic. In essence, with deterministic state, so long as you are using the same "ruleset" to govern the creation and modification of this state, independent observers witness the same result.

The notion of "decentralization" also does not apply to the state as it is deterministic. One should rather argue about decentralization in the context of who would be able to convince all followers of a ruleset to update or change their ruleset, if some update logic was not originally programmed into the ruleset. If ruleset update logic was baked in, then how control is designed here would I suppose determine decentralization. (Also why "side-chain" is a poor term, it is simply a ruleset, not a chain).

Consider this following as an example of why this is: a "blockchain" could store actions that were attempted but fail (e.g. alice tries to send bob money she doesn't have). All observers deriving state with the same ruleset, and given a consistent ordering of actions -- when they come to this action, all agree it fails. There is no theoretical reason to avoid storing this failed action, only a technical reason (to prune useless data). A 2nd layer solution functions in this fashion by having all observers of a "ruleset" agree on what succeeds or fails, even though failed actions will be stored. Bloating / storing too many failed actions is already limited at the base layer (e.g. resource credits).

The major drawback of this type of 2nd layer data is that it is encapsulated; it cannot cause programmatic actions to occur on other (or the base) rulesets. Crossing boundaries is active rather than passive, requiring some form of 2 phase commit (for example, atomic swap).