Let me try to clarify...
The link I had provided initially is probably not appropriate as it covers speeds at various signal levels and not the details how each speed works.
This may be a better resource:
http://mcsindex.com/
While they may appear similar on the surface. MCS rates are not 802.11a/b/g rates.
For instance, even at MCS0, the slowest rate, the speed is 6.5MBps or 7.2MBps, depending on guard-interval, which is already a bit faster than slowest rate of 802.11a or g. It also does not use the same modulation schemes as 802.11a/g (OFDM), or 802.11b (DSSS). So legacy clients wouldn't be able to connect since they wouldn't understand what's being said over the air, BUT as others have pointed out, as per the spec, you cannot completely disable OFDM data rates. For instance setting "data-rates custom basic-mcs-1s" produces a result of basic 6 and 6 + mcs-1s as supported rates. An alternative might be to specify "data-rates custom basic-36 48 54 mcs-1s mcs-2s mcs-3s". So at least your slowest speed would be 36Mbps if a 802.11a/g client were to be attempting any sort of connectivity.
You can use "show wireless radio detail" to see what actual rates end up being selected based on your configuration.
As Timo pointed out, you should also take into consideration broadcast and multicast traffic. By default these will be sent at the highest "basic" rate. So in the above example, this means all broadcast/multicast traffic will go out at 36Mbps. Obviously broadcast traffic being sent at 36Mbps is going to take more air-time, and air-time is actually the most precious resource in a WiFi network.
You can tell the AP to use dynamic rate selection among the supported rates when transmitting broadcast/multicast with the non-unicast tx-rate CLI command (use ? to see list of options).
In a MESH scenario there is no reason why you'd need the broadcast/multicast running any slower than normal traffic, so non-unicast tx-rate dynamic-all might be a more appropriate selection.
If you want to drill down further, the client probe requests/responses typically are also sent at very low speeds, this can also take up a lot of air-time. You can control at what speed the probe responses will be sent with the probe-response rate CLI command, but you can't easily control what the clients are doing.
Lastly, while there are many "knobs" available to tweak the operation of the radio / wlan, casual tweaking can lead to some pretty terrible results.