The only way to know this for sure is to run a workflow for a long period of time, and see what happens.
And since Zeebe 0.22 has been out for less than two weeks, no-one knows.
I ran workflows that lasted over a week on an earlier version of Zeebe. My observations were that memory use increased, and especially restarting nodes used way more memory when they had to reconstruct the current state.
We don’t recommend using Zeebe at this point for long-running workflows. With a database storing the engine state, such as the Camunda engine does, the number of long-running processes just increases the db size, which is not a big deal. And it is a table row mutation.
Zeebe is optimised for through-put, so it uses an in-memory state, and the event log is an append-only log. This is faster and more scalable than a database, however, it is more memory-intensive.
The event log on disk is pruned as snapshots are taken and as workflows complete, but the snapshot size and the memory use increases as the number of concurrent processes on a node grows.
In my case, I reworked my processes to be shorter-lived (around 24 hours) to reduce the memory pressure. With a low number of long-lived processes YMMV, but that is not the use case that Zeebe targets. It is designed for a high volume of short-lived processes.
For long-lived processes like the ones you mention, I would lean toward the Camunda engine. It is also extremely scalable (although not to the theoretical throughput limits of Zeebe). Some users put through millions of processes per day on the Camunda engine.