Sure, you can manually force Unix Time to go backward but that's very different from what is argued in the article. If you do time-aware processing and mess with the clock you are using, you can except troubles. That's in no way unique to Unix time.
Still, unless you actively mess with, Unix Time actually never goes backward.
It happens all the time. Go talk to ops/sre types who run large fleets and ask them for their time stories, also ask them how much infrastructure and scaffolding they have to have in place to ensure that such things are as rare as possible.
The consequences show up in large ways, as well, especially in distributed systems. Calculating an order of events, for instance, based on some notion of time is an obvious flaw. Even within a single system, assuming that a time stamp can be relied on to indicate order of events is wrong.
If you work in domains where these things are important you will eventually come to understand that simplistic and naive statements such as "unix time never goes backwards" are the swords that programmers eventually fall upon.
Still, unless you actively mess with, Unix Time actually never goes backward.