Well, yes, but then you've backed into CAP again because you only have one log.
The application state is defined by the log here, and the log drives retries/recovery, so it doesn't much matter if the process that executes the app code splits off. The log would hydrate another one.
Also the one log is at the granularity of a single key or handler execution. More of a logical log, than a physical log or even partition.
In Restate, we implement a logical log-per-key, backed by a partitioned physical log.
For something that is trying to solve the general problem of consistent single ground-truth log, you can't really do much better than Spanner.
The max clock skew also has to pick between A and C, in underestimates you lose serializability, in overestimates you pay in write latency.
Eventually the system implemented something similar to "find transaction timestamp at execution time" + optimistic locking, as the article states you lose global linearizability and have to do some re-reads for writes.
What I missed the most from Spanner compared to the system above is that its tricky to do client-side transaction chaining where there are many clients and the order is important.