Because of that bucket of problems people end up using these tools to manage terraform runs (also known as TACOs). Terraform Cloud is one of them; there's also Spacelift, Atlantis and a bunch of others covering various aspects of what terraform the language doesn't handle natively (ci/cd, state, tfvars management, dependencies, etc).
At the core though, this seems to boil down to a multi-graph comprised of states with some extra stateful pieces on top, like TFVars, inputs/outputs etc. All that's needed is a reliable service that manages these stateful bits in a manner that supports security and compliance needs (secrets stored safely, audit trail, etc). Currently all that is either not there at all, or part of a large "package offering" like Terraform Cloud or Spacelift.
The case I'm making is that this "logical core" needs to exist in a way that's not coupled to a do-it-all cloud-based solution. It probably should not be part of the language itself; but also shouldn't be an all-or-nothing proposition. Hence the VM / runtime parallel
Another parallel to express a similar concept could be "instrumentation for terraform" - it'd be odd if all the observability tooling for a particular language (say Java) were coupled to a cloud-based offering by the company that created said language (Oracle) right? There's a bunch of stuff outside of Java that most Java applications need nevertheless - like application server (eg Tomcat) and so on. Okay that's not exactly instrumentation; but then logging tools, monitoring tools, etc.
