I, personally, would argue against such a verbose JSON logging format purely for human readability purposes - the log format presented as an example has several human-unreadable IDs that could likely just be shoved in a fixed position in the string since people won't be able to decode them anyways and that would produce a more concise set of logs that would be easier to parse en masse visually with word wrap turned off while searching for the anomalous event.

JSON makes a lot of sense to me in logging if it's specifically something complex that you want a user to grab with copy-paste and dump into an interpreter for further inspection so having some supplemental detail fields be compacted in the JSON isn't a bad idea - but for the majority of the fields I'd prefer either fixed position or a more simplistic key=value (or key="value") format that can be more trivially read and is just as easy to parse.

Of course in a perfect world you want to ingest these logs into some better searching tool that lets you run SQL or some other standard query language over the set to prune them by date and pull out specific fields but there are times when you'll be hanging on by your nails with nothing to help diagnose the issue except an SSH connection to the server and the log file open in vi.