It worked just fine with Subversion. As long as the central server was fast and reliable there were no major synchronization problems. Branching was cheap, we did it every day.
Git is generally better for most workflows. But let's not pretend that it was ever really necessary for remote asynchronous development work.
I was comparing git as a local first software, and earlier in the thread, comparing it to local-first food systems. One of the properties of such is resilience. Maybe there are different ideas on what local-first means. However, when that subversion server went down, that halts synchronization. If the network was not fast or reliable enough, it slows things down. Those kinds of interruptions are exactly what was called out in the article posted by the OP.
In theory, perhaps. In the real world of team software development, Subversion server reliability was way down at the bottom of our list of tooling concerns.
And today most organizations drive their automated workflows from a centralized Git service. If that goes down then they can't deliver anything to customers, so they haven't really gained much resilience.
Git is generally better for most workflows. But let's not pretend that it was ever really necessary for remote asynchronous development work.