If one doesn't need particularly high data rates, it's possible to implement data-to-audio and audio-to-data routines in a very small amount of code. To store a "1", generate 250us of high followed by 250us (e.g.) of low; to store a "0", store 500us of high followed by 500us of low. Note that some tape-drives' electronics, which are designed for analog signals, will try to adjust the signal try receive so that it's high about half the time and low about half the time, and the signal may get badly distorted (and thus become illegible) if the high and low times aren't close to being balanced, which is why tape formats seem to waste half the storage capacity writing each bit twice.
If one is willing to use more complicated code for recording and playback, it's possible to use a mixture of different pulse lengths, encoded in such a fashion that the high and low times remain balanced. Such approaches can allow more than twice as much information to be stored as the simple straightforward technique, but require more code to read or write data. For a computer to include built-in support would have required that manufacturers devote hundreds of bytes of ROM to that purpose that could otherwise be used for other things.
For programs shipped on pre-recorded tapes, however, the size of the record/playback routines is not an issue. The data can be written on the tape using specialized equipment, making the size of the record routines irrelevant [if the encoding is one that couldn't be written by a standard computer, that would actually be a bonus]. The size of playback code is also not much of an issue. Even if playback code would take 1024 bytes, it could be used to load all but 1024 bytes of RAM; if it would be necessary to load even more than that, the last little bit could be loaded using a slower but smaller routine (or perhaps the built-in one).