Data rate for spi seems to be an ongoing source of question for people, so with the next release I’m going to make some slight changes to it. The value, nominally, sets up the speed that the spi clock runs at. It does this by specifying a divider for the system clock rate. However, right now there isn’t a direct mapping. 0 maps to a /2 divider, 1 to /3, and 2 maps to /4. (A quirk of how I set up some of the timing code initially).
The first of the two changes I will be making in the near future are making sure that the value maps directly to the divider - e.g a speed of 2 means an 8Mhz clock on a 16Mhz system, or a 24Mhz clock on a 48Mhz system. The second one will be providing a series of definitions so that you can specify the speed you want the spi clock to run at in Mhz/Khz, and do the math/juggling behind the scenes to get as close as possible.
Of course, with hardware spi you don’t get any rate you want, there are limits becuase the dividers are powers of two. For example, on the avr running at 16Mhz, you can have 8Mhz, 4Mhz, 2Mhz, 1mhz, 500khz, 250khz, and 125khz.
On the teensy 3, there’s a bit more flexibility because while the dividers are powers of 2, you can optionally multiply the divider by 2, 3, 5, or 7 to give you a bit more flexibility in the clock rates you run at.
The unfortunate thing I’m noticing is my own experience in helping others: the length of the string determines how fast you can shove data out. Too many times do I see people develop on a short string and set a data rate appropriate for that string, and then yell bloody murder when they transition to the final project with a much larger string and find it not working because the data rate is too fast. It’s hard to explain to people that a longer string will require a slower data rate …
Yup - it’s one of the reasons why I’m working hard to get good support for multiple strings in there. LPD8806’s I can push at over 20Mbit for up to about 160 leds, then it starts glitching. If, however, I can use hardware SPI, and a MUX to select between an arbitrary number of strands (ok, 16) - then that increases the number of LEDs that I can push at that high of a data rate.
This is also one of the things that I like about the tm1809 and ws2811 family of chips. They have a painfully slow clock rate, only about 800Kbps, however I’ve done some fairly long chains without signal problems. Of course, I can’t imagine trying to code up the ws2811 protocol at 8Mbit…
Also also, once I get DMA support on the teensy 3 going - slowing the data rate down won’t affect the CPU time that you have available to you, it will just affect what your maximum number of RGB led updates/second you can have…
Also, irritatingly, I can run the SPI clock at 24Mhz on the teensy 3, you would think this means I can push data at 24Mbit, right? WRONG! The teensy 3 by default inserts a delay equivalent to 1-2 clock cycles in between each byte or word transferred 
Add in the time spent waiting for the write fifo to clear at the end of updating a bunch of leds, and the real data rate hovers somewhere around 20.5-22Mbit… very very frustrating.
Are you using 5V, 12V, or 24V strings?
I use a mixture of 5 and 12v strings. The ws2811 and lpd8806 strips i’m doing the bulk of my current stuff with are 5V, the tm1809’s that I did a bunch of work with last summer were all 12v.
I’m discovering that many of the 12V ones are 3-LEDs per IC and most of the 5V ones are single LED per IC (which I prefer.) Need to do some digging for 12V, single LED per IC strings.
Look for TM1809 strips, it’s only 800khz data rate, but each tm1809 chip can drive 3 rgb leds independently (the ‘9’ in TM1809 - 9 outs 
- so a strip with 30 5050 leds per meter and 10 tm1809 ICs per meter gives you 30 individually addressable leds per meter (unlike the ws2801 - where 3-1 usually means addressing in groups of three).
Yes but I can’t cut them into individual ones if I need to.