The whole "Class 10" and umpteen MB/s alleged transfers are pure specmanship.
(specmanship, n.: The art of using misrepresentation and half-truths for purposes of marketing.)
Yes, you CAN, theoretically, see 10MB/s of writes - if they are sequential, and the card is new and unused, using a FS designed specifically to be good at sequential operations and nothing else (e.g. FAT). In practice, however, even that is unlikely after he card has been churned a bit. And yes, you will get 1000+ of random-read IOPS.
However, even on the festest Class 10 SD cards from the best manufacturers (SanDisk, Lexar, Kingston), you will get maybe up to as much as 20 random-write IOPS (hint: an ancient 5400rpm can do about 100 IOPS, read or write, so a SD card is about 5x slower on writes).
The slow writes will make the general percieved performance of using an SD card quite painful. It's workable - if you optimize your ext* fs for the card, and you LD_PRELOAD libeatmydata.so (eats fsyncs), and you put all the write-heavy stuff that doesn't need to be persisted across reboots on tmpfs (/tmp, /var/tmp, /var/cache/yum, /var/lib/yum, possibly even /var/log and a few other things, e.g. $HOME/.mozilla/firefox/.../cache). Coupled with zram and zcache, that makes for a reasonably usable system (although 256MB of RAM is going to be somewhat crippling for serious use of a R-Pi - small RAM and slow disk are not a good combination).
I use SD cards for primary disk storage on my SheevaPlugs, AC100s, DreamPlugs and Genesi Efika and the performance is quite acceptable - but all of those have 512MB of RAM. This is one of the reason I am moving over to newer Dream/Sheeva/Guru Plugs - eSATA + SSD combo makes for a system that feels as responsive as a full fat x86 desktop. Granted, by disabling tmpfs backing for the scratch space you will hammer your flash more, but it's the price you pay for having a big more breathing room out of tiny RAM.