OMG, I2C is... terrible, as others have commented, because a slave can hold up the bus 'forever'. Also, not frequently understood is the crappy protocol requires both CLK and DATA to be bi-directional in order to handle all the required states. Top that off with 3 different 'standard' speeds, two different addressing modes, non-standard voltages often requiring voltage translation -- I2C is just a terrible excuse for a bus. In fact, I've never met a practicing geek who likes I2C, as it's nothing but headaches dealing with the corner cases, and whacking the chips when the bus goes catatonic. Ugh. Just terrible.
And CAN? That's worse. I don't want to raise my blood pressure too much, so suffice it to say that CAN was invented in the 80s so it could be implemented with small amounts of code and fairly simple hardware because: 80s. It requires very careful planning of every message type. There is a limit to the # of messages you can have on any one bus. The bus is not one speed, could be many common speeds. It's a standard that needs to be put into the past ASAP.
What should we use instead? I3C is trying to supplant I2C, but SPI is clearly the simple, fast alternative. UARTs these days (e.g. the common CP2102) can do 3.8 Mbaud easily - that ain't too bad. And if you need anything approaching 'real networking' --- then, gosh, use Real Networking: Ethernet. Even poky 100 Mb/s 4-wire Ethernet is better than CAN.
(note: any technology can have a 'perfect' niche, so sure, in certain applications. I2C could be optimal, and so could CAN; but generally, I claim those are mostly legacy applications.)