There are a number of ways in which SPI signals may be generated. In some cases, a device will hardware which can be instructed to send the contents of a certain range of memory out to the SPI port without processor intervention. In such cases, there will generally be a uniform sequence of clock pulses, though it's possible there may be a "pause" after every eighth. In some cases, a processor will need to load each byte into a shifter which is capable of accepting at least one byte "in advance" of the one being shifted. The output in those cases will often look like that from the pure-hardware case, except that there may occasionally be random gaps after multiples of eight clocks if software occasionally fails to load the next byte before the present byte gets shifted out, but depending upon the processor's timing that might never occur. In the above cases, use of delayed-trigger functions on a scope may be helpful when examining regularly-formatted data, because everything will always (or almost always) happen at a consistent time relative to the start of a frame.
Things aren't always that nice, though. It's pretty common for devices to have hardware that can send out 8 bits automatically, but require software to wait until one group of 8 is sent before enqueueing the next. This creates groups of 8 regularly spaced clock pulses, with random amounts of space between them. This often precludes use of delayed-sweep functions, but on the flip side often makes identification of the start and stop of each byte easier than it would be if all pulses were uniform. The final possibility is that software may be generating an SPI signal by using a sequence of "set port high" and "set port low" commands. That is what appears to be happening in the sample above.
In most cases, the master device on an SPI bus (the RasPi in this case) is free to use any mixture of long and short pulses it sees fit, subject only to limitations on certain minimum pulse timings and, occasionally, maximum pulse timings which are often orders of magnitude above the minimums (e.g. a device may have a minimum pulse width and pulse separation of 250ns each, but a maximum time between pulses of 1ms--more than three orders of magnitude difference). Provided that pulse times stay within the very broadly drawn limits (and in many cases there would be no maximum limit) communication should be reliable.
The only time data loss is likely with SPI is when the slave device is a processor. The SPI slave hardware built into many CPUs requires that when a byte arrives, the processor must act before the master starts to send the next byte to avoid data loss, but provides no means by which the slave can tell the master it's ready; consequently, slaves often need to either use five lines to communicate with the master (clock, MOSI, MISO, CS, and a manually-implemented "ready" line) or else require that the master add a delay after each byte sufficient to accommodate the worst-case response time of the slave.