I'm more concerned about the concurrent trends for (a) remotely accessible systems in vehicles, for communication or otherwise, and (b) critical vehicle systems being connected via relatively insecure internal networking to each other and to something remotely accessible. It is possible to do much better and achieve roughly 4x the CAN-B performance (on metrics such as throughput, latency and robustness (all of them)), on the same bus. CAN-FD improvements really only suit niche applications. So the take-away here is, yes, CAN sucks, quite badly. CAN-FD hardly improves latency or the frame-rate, but it does much improve error-detection rates. That means bits are transmitted at only 22% of the datarate, worse for higher datarates, much worse for frames with only 8 bytes. CAN-FD increases the payload, stuffing 5x (typical) more databits in the same frame. Effectively the CRC is circumvented, so error detection rates are nowhere near the projections made in the design documents.

CAN-B error detection mechanism has holes in it due to bit-stuffing. a roundtrip takes 2 frames because the CAN request frame is broken to the point that standards like J1939 do not use it.

That means in practice one gets only 1500 frames/s at a typical 250kbps. For 4 bytes that drops to 25% so people avoid these frames. As used in automotive max 40% of all bits are actual databits. CAN is very slow despite high baudrates. Noone ever talks about the very significant downsides of CAN:

Ford ids license hack