Former lift industry hack, here (programming, not electronics).

As far as I remember, Gray code is used in encoders purely because it's "ideally" immune to bounce effects — Only one bit will change at a time, so you'll never see an effect like in standard binary where, for example, the transition from 3 (011) to 4(100) could essentially read as any permutation of ones and zeroes, because all three digits change state, but won't do so at exactly the same time.

Aside from that rather interesting property of Gray code, the cost of absolute encoders was all in the gearing. As for "expensive", our management liked it when the sales guys could sell an absolute encoder, because the markup on that single component would cover the cost of the whole of the rest of the job.

Can't say I was ever directly involved with development of the absolute encoder hardware, but from my recollection, the internal gearing essentially meant that an "absolute encoder" just meant that, where an electronic solution involved keeping count of revolutions of your standard encoder, the gearing of an absolute encoder essentially mechanised that counting process, meaning that you had absolute positioning within a given distance (like a lift shaft), but once you moved outside that distance, you were essentially lost.

This was useful in the elevator industry because in a 20m/s lift shaft, an electronic encoder solution could miss entire revolution of a standard encoder in between your processor's polling interval, meaning that you could lose your position at high speeds.

Pretty useful if you're travelling at eyewatering speed within a defined distance. Outside of that, I'd stick with an electronic solution of "counting how many times the wheel has turned round".

Anyhoo, I dunno if any of that was useful, but I'm done reminiscing now...