There was an encoding, in fact a very specific coding, designed to overcome the limitations of tape as a media, the biasing circuitry in tape heads and wiring polarity problems.
Granted, it was quite a simple encoding, but it wasn't just "straight-up 1s and 0s straight into RAM".
The bits of data to be output are encoded into high/low symbols representing the voltage on the pin, a 0 bit is output as HL and a 1 bit is output as HHLL, recorded at a nominal symbol rate of 855 T-states or approx. 4092 symbols per second.
In other words, both 0 and 1 bits are output as a pair of pulses with the 1 bit being twice as long as the 0 bit. If you had a continuous stream of 0 bits, it'd be a steady 2046Hz square wave, with a steady stream of 1 bits, it'd be a steady 1024Hz square wave.
There are many reasons why this scheme is adopted rather than the much simpler "high voltage=1, low voltage=0" which would be your "straight-up 1s and 0s straight into RAM".
The first main reason is that while the signal ends up as a perfect square wave, recording this to tape and reading it back doesn't give a perfect square wave, but instead a noisy wave that's more like a sine wave but with flattened peaks and valleys. This is very much in the analog domain.
Firstly, there's the conversion of the 0V/5V to analogue wave form, where's actually zero-biased to produced a +ve / -ve waveform. Ignoring all the weirdness on the tape, this is read back as a +ve / -ve waveform, amplified and rebiased to a non-zero voltage (so e.g. now the signal might be 1V-4V or it might be -1V to 6V). So now, converting that back to digital is hard - you need to choose an arbitrary cut-off voltage where lower is 0 and higher is 1, but you then find that then the volume changes the relative size of 0 and 1 bits when read back from tape.
The next problem is called "head biasing", but essentially the magnetic head needs to keep changing polarity to record a useful signal, but if the polarity of the head stays +ve or -ve too long it becomes saturated and resists change in the opposite direction, and so takes longer to change state. So for instance if you recorded a pattern like LHHHHLLH it might read back as LHHHHHLH. A video of mine that shows this effect is: https://www.youtube.com/watch?v=-GdPSnFswgk
The next problem is that tape motor speeds, tape can stretch, even oscillators in different machines can vary slightly and it's very unlikely that the signal you read back will be exactly the speed it was recorded at. You can "re-clock" on edge transitions, but if you have long stretches without a transition, it's hard to be certain how many bits were there.
Replacing a bit with a pair of pulses solves all of the above problems. There are several competing tape formats that use pairs of pulses - using output symbols HL and LH, which gives a constant bit rate, and the one used in the Spectrum of HL or HHLL, which is effectively frequency modulation and gives an average bit rate of 1500 baud (it'd be 1000 baud for all 1 bits, 2000 baud for all 0 bits). The latter was adopted almost universally, as it's simpler to decode on read - it's just timing the period of a pair of pulses (i.e. an entire wave). The former one requires slightly slower baud rates, but a related encoding is the basis of most early floppy disk encodings which use MFM.
There are alternative encoding schemes possible, just very infrequently used. I made a demo for the Amstrad CPC back in 2014 that tries to implement a turbo loader by clever use of output symbols, and it actually translates an entire byte at a time into a sequence of "overall balanced" pulses over a roughly uniform time period, and achieves a baud rate of 2687-3072. I was attempting to implement something like MFM coding used on floppies, but it wasn't quite possible with tape. This demo also had realtime decompression of data. There's more information on that here: https://github.com/ralferoo/breaking-baud/blob/master/docs/t... and you can see an example of it in action here: https://www.youtube.com/watch?v=NxX4fu6dAzo - when watching this be mindful that each screen is 16KB and would take 52seconds with the standard loader (same speed as the Spectrum standard loader).