Just picked up an ATP Electronics AF8GUD3A-WAAXX "industrial grade" 8G microSD from Arrow.
It's fairly expensive for an 8G card, at almost 27 USD, but believe it or not, this is a fairly good price for a high endurance industrial grade card. The price is much lower than competing SLC cards, because this card uses something they call "Advanced MLC" technology which seems to be their take on a trick used by several SSD manufactures which combines the high endurance of SLC single bit per cell flash with the higher capacity of MLC two bit per cell technology.
What makes this particular card special, is that unlike most microSD cards, this card is actually designed to act like a small SSD that just happens to be implemented in a microSD profile, with both static and dynamic wear leveling, plus advanced error correction and recovery.
This card is very fast and responsive, and is working really nicely with my Raspberry Pi 3. I'm not sure it's any faster than a Premium Samsung or SanDisk card, but all these high end card are limited a bit by the Pi's limited microSD throughput.
The only down side is that Raspbian has become so bloated that, with the full desktop installed, there is only about 2.7 Gigs of remaining disk space free. To overcome this I will probably use a trick I have used before, which is to move and remount my /home/pi folder to an external 64 gig thumb drive.
The main advantage to using an industrial grade card like this for the Pi's main drive is that if you are doing work like compiling large projects that really thrashes the file system with a lot of small temp files, you don't have to worry about the flash card wearing out and crashing your system.
If you don't want to invest in a high end industrial grade microSD there are some other tricks you can use to help avoid premature flash card failure.
One trick that has worked well for me in the past was to use a large higher end card, then leave HALF the card unpartitioned, so the card can use the unused space as spare cells as cells in the used partition area wear out. Lower cost non-industrial microSD cards most often use only simple "dynamic' wear leveling, where data being written is written to the least used currently unused data areas.
Even if the OS properly uses the SD erase commend and periodic trim to signal to the microSD card's controller which blocks are free, huge problems will eventually occur when the partition is nearly full, because, unlike "static" wear leveling which can move around existing data to optimize flash cell wear, "dynamic" wear leveling will only adjust where it writes NEW data. If only a SMALL portion of the partition is 'free', then the controller will only write to these cells. So, if you do something like compile a large project, or copy and move a large number of small image files, then ERASE those files and do it again, each time the controller will have no choice but to KEEP USING THE SAME SMALL NUMBER OF FREE FLASH BLOCKS. When the first few cells wear out, the controller will map in some from it's limited spares, and when those are gone, most controllers just lock the card to 'read only' mode and it's game over as far as the Raspberry Pi is concerned.
Leaving half the microSD card's space unpartitioned leaves all those unused flash blocks marked as unused, so the controller will know that it can move data there if it is needed.
I suggest that the Pi Foundation consider tweaking the raspi-config utility to allow an expand file system to half the microSD card's capacity option, because other than using an 'industrial grade' microSD like the ATP aMLC series above, this half-partition trick should provide the best chance of robust and reliable operation when non-industrial grade cards with 'dynamic' only wear leveling are used in active file system applications.
This half-partitioned trick is best done on a new microSD card, as after a card has been fully written it's difficult to guarantee that all it's unused area's have been properly trim erased to free up the blocks. Just writing all zeros or all ones to the device will not do this because it's actually a tri-state logic, i.e. ONE, ZERO, or, UNUSED. To gain the benefit of using an unused second partition's block as spares, we need all the microSD blocks in that block preset to UNUSED using a 'trim' operation.
Do any of our local Pi experts know for certain if the Raspberry Pi's Raspbian microSD driver will properly handle RAW trim commands like:
blkdiscard [options] [-o offset] [-l length] device
In theory, with simple MBR partitioning, there should not be anything of value after the last active block in the Pi's main BOOT and EXT4 partitions, so if we create a third empty partition, or just leave free space, we should be able to use these commands to 'trim' those sectors to an UNUSED state to insure that they are free for the use of the microSD controller as spare blocks.