Git is the native backend for jj. It is extremely reliable. There is no reason for "things to go wrong" uniquely to jj, particularly if you take basic precautions like forbidding force-pushes to master/main. For that matter plenty of people make mistakes with git itself, and having used both (and being a power user of git) I can confidently claim that there is significantly less surface area for mistakes with jj than there is with git.
I have never, in 25 years of software development, needed to "communicate my workflow" with another engineer. It's understood that if I use a different tool than the rest of my team, I'm on the hook for knowing any differences in the workflow. But it's not even like this is unique to jj; my team uses a variety of editors/IDEs, operating systems, and shells. I use macOS, fish, VS Code, and jj. Others use nix, zsh, vim, and git. Somehow we all manage.
The worst part is that your argument is trivially rewritten to discourage trying anything new. This is frankly a terrible mindset to have.
If you don't want to learn a new tool, by all means don't. But not learning anything that might be different than what other people on your curent team use is a great way to completely stagnate your growth.
That said, the argument I was responding to was that this can never take hold because of git's dominance. My point was that use of jj can grow organically since one person converting doesn't actually require the entire team to do so. Whether or not you're particularly hesitant to adopt new things is irrelevant; individuals can switch whenever they feel appropriate and it doesn't impact others.
Also, Rebasing is cause for Dev Riots because of nightmare merge conflicts that can result.
Since the author is from Google, my guess is they are seeing issues that hit the level of "WE MUST FIX THIS" that only arise at Google Monorepo size.