It's error prone. The constraints are well known & optimized for. The binary protocol will also have people implementing their own, poorly. Where-as one can get piping hot SIMD optimized JSON encoder/decoders.
I'm not 100% JSON all the time. But this response strikes me as crufty neckbeardy shit that ignores the obvious & good & uses negativity to step on a pretty clear & straightforward path. Having use d-feet & busctl dozens of times in my life, it's miserable. The encoding scheme is terrible & unpleasant. JSON is an obvious counter reaction, to try to make some damned sense. Given that these bus capabilities are more control plane than data plane (but it's not a hard line), it's ok.
Strikes me as a super bad attitude walking around with your nose way up in the air, leaving these farts behind you as you go. These comments aren't really couched in reality as far as I can see. They don't point anywhere specific, they're just broad swideswipes.
Here in the real world we keep reusing maybe so so protocols because they are scrutable & well implemented & we humans have lots of experience and tools using them.
You are 100% dead on, btw; thank you for saying! The overwhelming reason for varlink adoption is early boot, where dbus isn't up yet. That's a crucial fact here.
Varlink is a bit simpler, I'd say. It's more about individual services opening their own listening sockets, although there is an optional broker too. This somewhat simplifies the addressing model, a little. Messages are in JSON.
More and more of the systemd internals are being written or rewritten to rely on varlink for IPC, and the scuttlebutt is that eventually there's a goal to be able to run dbus free.