Sounds like a good solution. If running at normal speeds when transmitting there should be very little error in the width of the pulse sent.
Another approach if there were more drift in operating frequency would be to send, say, a 100ms pulse as a reference which represents 100% of 10V, then you can send a second pulse which represents the percentage of the battery with respect to 10V. For example 5V would be 50ms, 10V is 100ms, 15V is 150ms, 20V is 200ms.
Drift usually happens slowly over time, and any error in pulse widths sent close together should be proportional. If the 10V reference pulse became 75ms a 15V pulse would be 112.5ms. Then 112.5 * 100 / 75 = 150, 15V.
That's just an idea, not saying you should do that.
Given that you are using what looks like dumb 433Mz modules they may not be as bandwidth limited as you thought they were and you probably could send serial up to 1200 baud or even higher.
Also, sending long pulses may actually be less reliable than sending serial. What tends to happen is that receiver 'loses lock' on the signal if it doesn't change over time so it may lose lock more on long pulses and gaps than it would with more frequently changing bits of serial bytes.
One thing to watch out for would be, that to get the receiver to initially lock, you may need to send a series of high and low pulses before every data transmission. That can sometimes be easier using serial.
The great thing about software projects is they can be changed if something doesn't work as well as expected. So I would go with what you propose and, if it turns out to be as reliable as hoped, you are done. If not you can contemplate doing it some other way.