I wrote some C code to test the Raspberry Pi capabilities. For now it is hardcoded to send ON to first device of first remote I used. There's two versions, other uses bits like I initially thought they would be and the other uses shorter KaKu-like bits.

Capturing the data with a logic analyzer shows it sure looks a lot like the data captured from original remote control. There is no noticeable differences between the two versions, so I'll stick to the first one. However analysing the data with remote payload parser there seems to be something that does not look promising. This is a snippet from a random range showing the precise time spent in each state.

time: 1089.000000 µs, state: 0
time:  340.500000 µs, state: 1
time:  287.000000 µs, state: 0
time:  286.250000 µs, state: 1
time: 1090.625000 µs, state: 0
time:  340.125000 µs, state: 1
time:  290.375000 µs, state: 0
time:  285.000000 µs, state: 1
time: 1089.750000 µs, state: 0
time:  338.375000 µs, state: 1
time: 1086.250000 µs, state: 0
time:  283.500000 µs, state: 1
time:  282.125000 µs, state: 0
time:  280.250000 µs, state: 1
time:  286.125000 µs, state: 0
time:  282.000000 µs, state: 1
time: 1087.875000 µs, state: 0
time:  284.000000 µs, state: 1
time: 1086.625000 µs, state: 0
time:  284.625000 µs, state: 1
time:  282.250000 µs, state: 0
time:  280.750000 µs, state: 1
time:  297.875000 µs, state: 0
time:  282.500000 µs, state: 1
time: 1085.000000 µs, state: 0

It is not consistent enough. The pulse lengths should be about 250, 1250 and 2500 microseconds. Even after I changed the delay in code to 200 µs the variation is between 260 and 380 µs for the shortest pulse. Longer delays should be 1000 µs, and it does not vary so much as the shorter pulse. I switched the logic analyzer to a 433MHz antenna and the code worked only on about every fourth attempt. Spamming the payload more than 6 times may work, but it does not seem trustworthy. The Raspberry Pi GPIO pins might not be accurate enough for sub-millisecond scale delays.