The SD card standard has evolved in much the same way as the IDE standard over the years - ie. it's got very complicated and confusing. It doesn't help that card manufacturers tend to stay well away from real technical data when publishing performance claims or even choosing/maintaining model branding, so it is genuinely difficult to tell from the outside what a card is likely to do.
The bottom line however is that an SD card has two components: a flash chip which is used for storage, and a controller chip which interfaces between the flash chip and the card connector. A very similar controller chip is used for USB flash drives.
The card connector can be run in a number of different modes and at a variety of different speeds. Obviously the card and the computer have to support the same mode and the same speed in order for the two to work together. To simplify matters, the card always comes up first in a standard, rather slow mode which all computers (and other card readers and writers) must support. The computer and the card then negotiate a faster mode if possible.
The original SD card standard (and thus the standard, slow mode mentioned above) operates the interface at 3.3V. This supports up to 50MHz SDR signalling and 4 bits per clock, which is technically sufficient to support anything up to and including a Class 10 card, but some applications really prefer more than that.
Recent high-performance cards tend to support the new interface standard known as UHS (Ultra High Speed). This changes the interface voltage to 1.8V to allow faster speeds, but only when the computer and the card both support this and have negotiated such - so the card still initially comes up at 3.3V as normal. UHS supports DDR signalling giving effectively 8 bits per clock, and up to 104MHz clock speeds.
The problem seems to be a hardware bug in the Broadcom chip's SD card interface, which prevents it from supporting 1.8V signalling properly. As long as the interface is kept in 3.3V mode, it works correctly. Since all SD cards support 3.3V mode, albeit not necessarily at their maximum performance, this is a solvable problem - simply ensure that the firmware and the Linux kernel know that UHS support is broken so that they never use it.
By the look of it, the firmware is already staying in 3.3V mode and thereby loading the kernel correctly. Linux however is trying to be clever and turning on the UHS mode - and only then noticing that something is wrong, hence the error message mentioning 1.8V. Linux is then unable to recover the SD card hardware to a working state.
So the bottom line is, as I mentioned before, that Linux needs to be told that 1.8V UHS mode is unavailable on the R-Pi.
The key to knowledge is not to rely on people to teach you it.