While I agree wholeheartedly about the fact that USB is a disaster for interconnect, CAN is a mixed bag.
The fact that CAN systems are limited to 8 bytes a transaction is a blessing and a curse. If everything can fit in 8 bytes--and generally broadcast--then CAN is awesome. It is fully differential. It has a really good autobaud algorithm. It has CRC and bit stuffing to avoid too many 1's or 0's in a row. It automatically retries under most conditions. It has a specified arbitration algorithm if two devices attempt to grab the bus.
If, however, you start needing bidirectional transactions or transactions larger than 8 bytes, it's not so good. And, one of the big problems today is that secure channel setup almost always requires bidirectional exchanges larger than 8 bytes.
Under most conditions, nowadays, you should probably reach for Ethernet, first. There is a reason why practically every standard (Ethernet, HDMI, USB-C, Displayport, Thunderbolt) has converged to 4 matched pairs for data transmission.
The single condition nowadays that would drive you towards CAN is truly deterministic, hard real-time timing.
I have worked with CAN on spacecraft and it was always a great option for what we needed. It is used as the critical communications bus on the spacecraft where the real-time timing is needed. So systems that control telemetry, tracking and control (TTC) and attitude determination and control of the spacecraft are usually run on CAN or something similar.
But there is always a mix of communications standards. For higher speed data (such as from an imaging payload) then other standards such as Ethernet, LVDS, Spacewire, etc. are used.
For a critical communications bus in space there aren't that many good options. CAN and MIL-STD-1553 are probably the most common that you will find. I have worked with both and CAN is definitely much nicer to use.
The fact that CAN systems are limited to 8 bytes a transaction is a blessing and a curse. If everything can fit in 8 bytes--and generally broadcast--then CAN is awesome. It is fully differential. It has a really good autobaud algorithm. It has CRC and bit stuffing to avoid too many 1's or 0's in a row. It automatically retries under most conditions. It has a specified arbitration algorithm if two devices attempt to grab the bus.
If, however, you start needing bidirectional transactions or transactions larger than 8 bytes, it's not so good. And, one of the big problems today is that secure channel setup almost always requires bidirectional exchanges larger than 8 bytes.
Under most conditions, nowadays, you should probably reach for Ethernet, first. There is a reason why practically every standard (Ethernet, HDMI, USB-C, Displayport, Thunderbolt) has converged to 4 matched pairs for data transmission.
The single condition nowadays that would drive you towards CAN is truly deterministic, hard real-time timing.