Ich glaub CAN ist im Hobbybereich einfach nicht die Lösung. Ich würd jetzt behaupten, dass für Hobbyisten Arduino guter Standard ist und das its (ohne Erweiterungen) nicht mit CAN kompatibel.
"Arduino" ist ja ein ganzes Universum aus Libraries, IDE-Unterstützung und Board-Unterstützung. Man kann davon halten, was man will, ist bei Vielen auch verpönt, mir persönlich gefällt es allerdings sehr, da man nicht erst mit dem Buildsystem kämpfen muß und eigentlich direkt loslegen kann. Manche etwas seltsame Abstraktionen muß man dann ja nicht nutzen. Und selbstverständlich kann man damit auch CAN nutzen. Vielleicht gibt's auch irgendwelche Software-Stacks für CAN, mit Hardware-Controllern wie dem MCP2515 ist das absolut kein Problem. Genügend "ordentliche" Microcontroller bringen auch CAN-Controller mit, da muß man dann nur noch einen Transceiver anschließen. Problem: Aktuell wahnsinnig schlechte Erhältlichkeit der Teile, dadurch ziemlich nervig in der Entwicklung. Der ESP32 hat einen CAN-Controller und ist billig, aber irgendwie ist mir das zumindest aktuell noch ein wenig suspekt.

Allerdings muß ich Dir natürlich insofern zustimmen, da CAN eine komplexere Geschichte ist, was die Nachrichten auf dem Bus angeht, insbesondere die etwas verquere Adressierung mit integrierter Priorität und die für moderne Verhältnisse sehr kleine Nachrichtengröße erfordern natürlich, daß man schon sehr genau darüber nachdenkt, wie denn das Protokoll zur Steuerung aufgebaut sein soll.
Die neueren Teensy Boards haben CAN Schnittstellen, aber die sind um die 20€ einfach zu teuer um damit "nur" ne Lampe anzubinden.
CAN ist eigentlich in vielen besseren Microcontrollern integriert, aber die kriegt man halt aktuell einfach nicht zu interessanten Preisen. Wenn man da was umstellen will, muß man natürlich alles auf einmal umstellen und dann braucht man schon eine Handvoll Knoten, weshalb man da gerne etwas nehmen will, das erträglich kostengünstig und vor allem auch klein ist. Naja, irgendwann gibt's mal wieder Bauteile, dann wird das alles besser.
Ich meine mal gelesen zu haben, dass I²C, obwohl es dafür nicht ausgelegt ist, in der Praxis doch relativ gut geeignet ist um "längere" Strecken (zB im VM) zu verbinden. Hat da irgendwer Erfahrung mit?
Erfahrung nicht, ich würde aber davon abraten. Man kann das machen, wenn man spezielle Bustreiber einsetzt, die die Pegel anpassen, aber I2C war als Kommunikationslösung zwischen Geräten auf einer Platine gedacht und ist auch dementsprechend designt. Wenn man gerne Industrielösungen einsetzt, kann man das elektrisch beispielsweise auf RS-485 basieren lassen und dann irgendein Protokoll darüber laufen lassen, muß ja nicht gleich Modbus sein

. Ich würde generell für solche Anwendungen etwas nehmen, das differentiell überträgt, um ein wenig störimmuner zu sein. Ob man's braucht, wer weiß, aber schaden kann's erstmal nicht.
edit: gerade das hier gelesen:
https://hackaday.com/2017/02/08/taking-the-leap-off-board-an-introduction-to-i2c-over-long-wires/ ... I²C über längere Strecken kann wohl funktionieren, ist aber prinzipiell doch nicht so mega.
Letztendlich muß man sich fragen, welchen Zweck die Kommunikation zwischen einzelnen Knoten erfüllen muß und insbesondere, ob man einen zentralen Controller will oder ermöglichen will, daß die Knoten auch untereinander kommunizieren. Meines Erachtens nach ist es geschickt, Kommunikation untereinander und auch Broadcasts oder Multicasts zu erlauben, da das System so flexibler ohne Konfigurationsänderung erweitert werden kann. Das macht aber natürlich das Design ausgesprochen aufwendig. Wenn man das alles nicht braucht, spricht meines Erachtens nach wenig dagegen, einfach einen UART zu nutzen und darüber mit einem einfachen Protokoll die Daten zu übermitteln.