It was used as an industrial communications bus to coordinate slave devices from a master controller. Drop-length was a non-issue as the majority of our devices used an in-rail (DIN mounted) interconnect bus. The larger "drops" were often a under 10" and just jumped one DIN rail to the next DIN rail in the cabinet.
This was selected for the following reasons:
1. These devices were installed in HEAVY EM environments (think in close proximity to very large electric motors) and the electrical characteristics
2. The system topology physically supported multi-drop
3. We had a good deal of talent with CAN experience
4. Our device was already supporting a bunch of wired and wireless protocols (rs422, rs485, ethernet, btle, wifi, etc) and tbh CAN support was a gimme on the SOM we used as the device's core, so initially it made it into consideration by chance
Many (all?) CAN standards transmit on redundant copper, in opposing polarities, making it really easy to identify a signal vs noise. https://en.wikipedia.org/wiki/CAN_bus#/media/File:CAN-Bus-fr...
It's like a one-wire serial signal, but redundant.
Google is using it internally for their servers. Many rack providers have implemented it for server rack monitoring, …
CAN is cheap. You get it in almost every micro-controller. Requires less overhead in micro-controllers than Ethernet. Is much more reliable than Ethernet if you leave controlled room conditions. It is mostly cheaper if you have to factor in all-over costs like cabling, switches, management.
It is everywhere where you don't see it, where you just care that the system needs to work with less management as possible.
And real time latency is not "dead simple". A low priority message will always lose out to a higher priority message on CAN. With ethernet a low priority task can flood the bus if the circumstances are right.
Also, which MCUs come with gigabit ethernet?
I answered the Formula 1 MCU's (Motor Control Unit). Maybe the official one from Illmore already (I think), and some of the internal ones used for testing (which I worked with).
The NASA Space Shuttle also had several dSpace controllers on board (RTLinux with special IO drivers) and I guess modern rockets and planes also will switch to Ethernet also. It's 1MHz vs 1GHz. It makes a difference when you can afford a fast CPU, i.e. high speed controller and you don't want to wait for CAN messages coming in every 1000 cycles.