Questions regarding messages for SPI protocol
I use SPI to communicate between two STM32's in some of the products I design, it works well, but there are some gotchas. 


  Can I assume SPI is kind of 100% reliable? (meaning no bytes are lost,
  the Arduino/STM32 will be within max 10 cm/4 inches difference) ? (if
  yes, the following questions might be less critical). I don't need a
  super fast speed.


SPI is not 100% reliable, it is susceptible to noise, especially common mode noise. This means having a solid ground between devices. If this is a board-wire-board bus then it could also be more susceptible to noise. If you have switching power loads, this also may crate noise. 

Speed and error rate go hand in hand, in general higher speeds are more susceptible to noise and the error rate goes up. The problem is in rise times (mostly from capacitance) of the bus. The higher the speed, the more likely rise times and ringing will become problematic. 

I would think if your running less than ~5MHz you should be fine. Use good EMC/EMI control, check the rise times of the SCLK and give the clock time to settle, this should minimize error rate. 


  Is it a good way to have messages of different length? Rationale: When
  the command byte is not read correct, the number of data bytes is
  incorrect, and all consequent bytes will not result in valid messages.


This is all dependent on the software you want to write, I prefer fixed bytes. The most likely error is probably going to be from a bit flip, not a missed clock (if your running the bus slow enough). 

Another thing to consider is to add interrupt lines to the spi bus for hardware flow control if you are rolling your own software. This makes it easier to tell which processor is talking, I'll usually a CS line from the master to slave, but also one from the slave to master, so you don't have to poll all the time, just handle the interrupt if the slave wants to talk (not needed if you have communication that is one way only). 


  To prevent this, should I add some 'end bytes'? Or is there a better
  way to solve the problem of misreading (e.g. the command byte)? And if
  the end bytes would be e.g. 255, should I make sure 255 is not used in
  the command or data bytes?strong text


Hardware flow control is best, if you need reliability then use a CRC byte/scheme to make sure the message has been sent correctly. Use the CS line to figure out when the message is over.