Very nice! I especially like that it starts with a discussion of why you would choose to use I2C, as well as why you may not, depending on your application:
>I2C is not appropriate for all applications however: When higher bandwidth is required, SPI may be the right choice and can be found in many NOR-flash chips. MIPI can go even faster, and is often used in displays and cameras.
If reliability is a must, CAN is the bus of choice. It is found in cars and other vehicles.
When a single device is on the bus, UART may work just as well.
Article misses two of the best features of CAN: Built-in, non-corrupting collision resolution (lowest CAN ID wins) and CRC-protected frames. The latter feature is usually done by hardware, just as in Ethernet.
CAN also autobauds so if you have frequency drift it compensates. That's why it forces bit transitions via bit stuffing if it gets too many 1's or 0's in a row.
I would not call bit-resynchronization as "autobaud". Because CAN has no autobaud.
That said, with Classical CAN you can implement an autobaud (better: automatic bit rate detection) like mechanisms when you can make some assumptions on the used bit rates. With CAN FD and the upcoming CAN XL you cannot do that.
PS: Baud is a term specifically applying to communication systems that transmit symbols and a symbol can represent more than a bit. That is why I2C, SPI, LIN, CAN, Ethernet have a bit rate. While RS232 has a baudrate, which is different from the bit rate depending on the type of symbol used.
>I2C is not appropriate for all applications however: When higher bandwidth is required, SPI may be the right choice and can be found in many NOR-flash chips. MIPI can go even faster, and is often used in displays and cameras. If reliability is a must, CAN is the bus of choice. It is found in cars and other vehicles. When a single device is on the bus, UART may work just as well.