Just to add my '2 cents'....
I2C is a broadcast protocol - ie each message is received by every device on the bus. But part of the message is a unique 'address' (bit like a phone number) - and each device must have been set up with its own unique one. So when the message is sent then 'all but one' of the devices will ignore the message as its not their phone number.
I2C does allow you to send a special message (with an address of 0) that ALL devices will receive - but none are allowed to respond to (as they would be talking on top of each other). This is useful to send a message like 'I have just been reset so please will you all reset/initialize yourselves'. You can also simulate I2C in software which is only really worthwhile if you have two devices with the same address and they cannot be modified (or if you have more than 127 devices!). You cant put them on the same bus as they conflict. So putting one onto a software simulated bus avoids the problem.
SPI on the other hand uses a digital output to select the one (and ONLY one) device that the message is being sent to. Hence adding +1 pin per device as per Waltr's post. If you have lots of devices then you can reduce this a bit by adding an extra IC to decode a value. IE if you have 8 devices then you would need 3 processor pins (as 2^3 =
going into the IC and it would then set one of its 8 output pins accordingly. Cant think of the name or part number off the top of my head but its probably something like a 'multiplexer' or 'de-multiplexer'. Another advantage with SPI is that its very easy to simulate in software. By doing so then you can forget the the device selection pin and just tie it on the target device to ground so that its permanently selected (since its the only device on the software simulated bus).
Another consideration is 'what needs to talk to what?'.
SPI only ever has ONE master and MANY slaves. The 'master' initiates all phone calls and hence a 'slave' can only reply if it has been asked a question. Hence if the master is your Axon and the slave is a distance sensor then the Axon would need to keep polling the distance sensor to see if there is an obstruction ahead.
I2C on the other hand allows (in theory) each device to be a slave AND/OR a master (at any one point in time) - so anything can talk to anything else. With the above 'example' this means that rather than continuously polling the distance sensor you could make the distance sensor broadcast a message (to anything thats interested) to say 'I see something'. Unfortunately the ATmel/AVR hardware implementation for this is a bit flaky.