Why DS ROM loading from SD was not worth waiting for

nds-bootstrap is shit, and is fundamentally broken from a design perspective.

To understand why you'll need to understand a bit about the hardware. It's best to illustrate by analogy.
Here's a simplified diagram of the Wii's guts.

          WII INTERNAL SCHEMATIC

             +-----------+
             |           |
             |    RAM    |
             |           |
             +-----+-----+
                   |
+----------+       |      +---------+
|          |       |      |         |<----------USB/Bluetooth
| Broadway |       |      | Starlet |<----------Disc Drive/SD/NAND/USB
| PPC CPU  +-------+------+ ARM CPU |<----------GC Controller/MC
|          |       |      |         |<----------Etc...
+----------+       |      +---------+
                   |
             +-----+-----+
             |           |
             | Hollywood |
             |    GPU    |
             |           |
             +-----+-----+
                   |
                   |
                   v
                  TV
The Wii was an easy console to run pirated games on.
Games for the Wii ran on the Broadway CPU and Hollywood GPU. Developers were completely unaware of another embedded ARM CPU called Starlet and wrote programs simply for Broadway and Hollywood.
Starlet was responsible for security on the Wii. The programs Starlet can run are called IOS and there are a few different versions of it to ensure compatibility with different games.
When a game attempts to start, IOS verifies that the disc is in fact a real Wii or Gamecube game and loads the game's code for Broadway to run. Whenever the game wants a file from the game disc, IOS will load the file and check if it has been tampered before letting Broadway use it.
It didn't take long for pirates to start modifying IOS, calling their custom versions cIOS. The first cIOS simply removed the checks for legitimate discs. You could write a program that boots your game with the cIOS and it just works. The game is unaware of the change, since Broadway is not concerned about security. Patching a handful of IOS is much easier than patching every single game and it works transparently.
But that's not all you can do. Since all the SD and USB hardware is hooked up to the Starlet too, whenever a game asks then cIOS can just retrieve data from there instead of the disc. Again, the game has no idea anything has changed - as far as the game is concerned, it is still asking for data from the disc! The fact that this one CPU which you can control in between the game and the data makes it very easy to redirect file requests and perform tricks like USB loading or NAND emulation with very high compatibility.

Why is this relevant? Well, in DS mode, the 3DS functions just like a DSi and it's not really possible to selectively choose which 3DS features you want and what DSi features you want. It IS however possible to choose which DSi features you want and which NDS features you want, even in the middle of a game.
Here's how the DSi basically looks inside.

                       NDS/DSi INTERNAL SCHEMATIC

                             NDS Card slot
                             GBA Card slot
                                 Etc.
                                  ^
                                  |
                                  |
                                  |
        +-------------------------+-----------------------------+
        |                         |                             |
        |                 +-------+--------+                    |
        |                 |  Main Memory   |                    |
        |                 |16MB in DSi mode|                    |
        |                 |4MB in NDS mode |                    |
        |                 +----------------+                    |
        |                                                       |
        |              +-----------------------+                |
        |              |     WRAM     VRAM     |                |
+-------+-------+      |800 KB WRAM in DSi mode|        +-------+------+
|               |      |32 KB WRAM in NDS mode |        |              |
| ARM9 Main CPU +------+      656KB VRAM       +--------+ ARM7 Sub CPU |
|               |      |  Broken into blocks   |        |              |
+-------+-------+      |  which can be given   |        +-------+------+
        |              |  to ARM9, ARM7 or GPU |                |
        |              +----------+------------+                |
        |                         |                             |
    +---+---+                     |                             |
    |       |                     |                             |
    | "GPU" +---------------------+                     Touch Screen input
    |       |                                           Sound input/output
    +---+---+                                                SD/NAND
        |
        |
        |
        v
     Display

DS games mainly run on the ARM9 CPU. You'll notice that the ARM9 has direct access to the DS slot. This illustrates the first biggest caveat - There is nothing to intercept DS card reads. DS games speak directly to the cartridges and there is nothing you can use to redirect those requests elsewhere, unless you have your custom hardware in between the console and the ROM (i.e. a flashcard). So now you have to get stuck into the game's code and write a whole bunch of patches for every game with their own individual quirks.

There's another problem. Most card reads are done from ARM9, but only ARM7 has access to the SD hardware. Not only do you need to patch the main game on ARM9 to replace the card read requests, you also need to modify ARM7 code so that it will accept these requests from ARM7. Fortunately ARM7 code is all pretty similar - similar to IOS, it's provided to developers by Nintendo and interacts with ARM9 through an interface that's mostly the same from game to game. This makes it easier to write patches for ARM7 and is why ARM7 donor binaries can be used for nds-bootstrap.
SD speed is not an issue here - rather, the bottleneck is the communication between ARM9 and ARM7. It's really not suited for this sort of data transfer at all and this is why it's so slow.

There are a few things that can be done to improve speed. The first is to implement a cache. All the data obtained from the ROM is kept in an additional area of memory. As more reads are done, old data is pushed out of this memory area and replaced with new data. If ARM9 tries to read some part of the ROM that was recently accessed, then instead of asking ARM7 and waiting ages for a reply it can just get it straight out of this region of memory.
The extra 12MB of DSi memory seems like a good choice for containing the cache. Unfortunately, this can't be enabled without breaking memory mirroring (If a DS game running in DS mode tries to access the data at the point 5MB into Main Memory, it'll actually loop around and get the data from 1MB in. However in DSi mode, it will reach the memory at the 5MB point as expected. Many DS games rely on the loop-around functionality.)
Fortunately, the DSi has 768KB of new WRAM too, and it can be given to either CPU without causing any new conflicts. Use of the new WRAM as a cache was introduced in nds-bootstrap 0.4.0 and is responsible for the noticeable increase in loading speeds there, especially in cases where the same portions of the ROM are being accessed repeatedly (e.g. swimming in SM64)

There are additional things you can do to improve the load speeds like cache prefetching (predicting what ARM9 will want before it asks for it) and parallel execution (better sound, less stutters in gameplay) but in the end this is all just polishing a turd.
The fundamental point is that the number and complexity of all these patches ensures that high compatibility is out of the question. Especially as later DS games force anti-piracy checks, these things will flag up and they will cause issues. Even those games that work with nds-bootstrap will always work better with a flashcard.

tl;dr Buy a fucking flashcard poorfag.