Why do we send some dummy data before sending any command to a microSD card?
The SPI bidirectional protocol requires that any time the master might try to exchange a byte of data, the slave always be ready to take in a byte of data and spit one out.  The master will feed the slave a byte on MOSI without regard for whether or not the slave is ready to do anything useful with it, and whatever the slave does on the MISO pin will be interpreted as a byte of data by the master whether or not the slave had anything useful it wanted to say.

To deal with this, many SPI chips define their behavior such that the first byte following a chip select will indicate whether the device is ready to do anything with a command request other than drop it on the floor.  Effectively, the first thing the master does is ask "are you ready?"  If the slave answers "no", the master may ask repeatedly as often as it wants until the slave says "yes".  Such a design is fairly simple to implement on the slave side, and is fairly easy to use from the master side.  Further, it's generally not to hard to subdivide the different kinds of operations a device can perform into steps which are small enough that once the slave is ready to begin performing a step, it will be able to exchange all the data with that step as fast as the master cares to clock it, without further delay.

One slight wrinkle in all of this is that some slaves may need pulses on the clock wire in order to perform certain operations.  As a common example, many designs expect to latch all 8 bits of the next byte they're going to send before they receive the first clock pulse.  If a device which is primed to send a byte that says "not ready" becomes ready, it would have no way of knowing whether a clock pulse might arrive just as it was getting ready to change the next byte it transmitted, causing that byte to contain a mix of old and new data.  One way of avoiding such a danger is to have a device decide on the sixth clock cycle of each byte whether it's going to report itself as ready on the following byte.  Even if the device becomes ready just as it receives the sixth cycle of a byte, by the time the eight cycle was received the device would have had a chance to make up its mind as to whether it thought it became ready before the sixth cycle (in which case the next byte should report "ready") or failed to do so (in which case it should report another "not ready" byte).