So far as I'm aware, CAN makes a lot of sense when it's no longer just two devices talking to each other, but a bunch of devices talking amongst themselves. Using UART for the same scenario would result in a lot more signalling wires, whereas CAN only requires a single, twisted pair of data lines that are shared by all devices.

Automobiles followed a similar progression, since CAN was a product of Bosch. Initially meant to simplify the connections between engine sensors, it later proved useful all around a car, from the switches that control power windows to the adjustment of power mirrors. Most importantly, it signals between all of those decices using just two thin wires.

For ebikes, the mandatory data path is between the user display and the motor, so UART worked fine. But other peripherals like brake, speed, and gear sensors, those had their own wires, all having to go to a central controller somewhere. So might as well use CAN to simplify the wiring and maybe add new functionality:

Imagine the display has a button to enable the headlights, and that sends a CAN signal to the controller to close the relay for the headlights. But maybe you have an auxiliary headlight that reads the same signal and turns on as well. And maybe the taillight also turns on, plus a wireless relay so that the lights in your pedals also turn on.

CAN is acceptable to wire two things together, but it really shows when building a cohesive network of peripherals. Unlike modern computer data networks, all devices on a CAN bus receive the same messages and so they can all react to the same "broadcast". I have personally sniffed the CAN bus on an automobile to implement some nifty integration with a dashcam. Maybe we might have CAN be how a GPS bike computer continues measuring speed using the wheel sensors, even when in a tunnel.

That said, I'd be remiss if I ignored a major downside of CAN: because it's not drop-dead easy to examine like UART, some manufacturers will implement strange, proprietary message types using CAN. This makes it harder for users to intercept or modify those signals, since there isn't any documentation. Reverse engineering is sometimes needed to deduce the meaning of certain CAN messages. Ideally, industry standardization around CAN and ebike sensors would mean they're all compatible with each other. Or at least, I hope that happens.

Still, I'm of the opinion that CAN is light-years preferable than every manufacturer reinventing their own data bus. The electronics community has been poking and proding CAN for decades, so using CAN means less reverse engineering overall.