So basically it would be sufficient to check if the card is busy in checking if DO is low, and only send commands and / or data packets to the card when DO is high
Won't work. Please read the following carefully.
When you write to a file, a large number of SD commands and operations operations are required. There is no way you could check for busy before executing this statement.
logfile << charBuf << flush;
This statement may require a cluster to be allocated. That requires reading FAT blocks until a free cluster is found. Updating the FAT block in memory, writing it back to the SD, then updating the backup FAT. Even if you write 512 bytes, the data may cross a block so there could be read of a block, copy part of the data to that block, write the block back, then write a second block. Then the flush requires reading the directory entry for the file, updating the directory entry and writing it back.
The SdFat library does check for busy before every write since the write would fail otherwise. The problem here is that the card won't indicate busy until you send the write command. Then you must wait before sending the data packet. If you write a RU which may be 16 KB, there may be 32 busy periods.
SdFat can't check for busy before reads. The card sends a stream of busy tokens for read and finally sends a start data token.
No reasonable SD library can do what you want. Chan's FatFS does not have a non-blocking mode. FatFS is widely use and the latency problem is handled by using FatFS in an RTOS.
I also have a new replacement for SdFat that I use in RTOSs like ChibiOS and FreeRTOS. The problem is simpler on ARM processors with more features than Teensy. You can use SDIO and write a driver that sleeps while the SDIO controller does all the busy checking for a large read or write. Other threads run and no CPU time is lost in busy checks.
There is another possibility. You can create a large continuous file and write it with low level SD operations. You must still buffer data but the check of MISO should work.
This program used one large multiple block write and avoids most busy periods. It can log data much faster than your requirement on an Uno Try this super fast analog pin logger - Storage - Arduino Forum .
I did a reliability test logging five analog pins at 5,000 samples per second. This is an ADC rate of 25,000 values per second. I logged 512 MB of data without dropping any values.