It's an interesting mechanism, and one usable for a lot more than protecting router-protocols.
Since TTL is a 8-bit field, there's no way it can be set higher than 255, and if the routers around you work properly, they will decrement TTL by (atleast) one for every packet coming trough. (exception: "transparent"-mode where routers pretend not to be there)
By insisting, at the kernel-level, that packets coming in to a certain socket must have a minimum remaining TTL, you can in essence say: "only accept packets to this socket, from machines which are 'close' to me. Where 'close' is interpreted in a network-sense.
I have a home-network with a router, and a second router that serves as my gateway to the internet.
If those both work correctly, it means I can never get a package from the internet, with a TTL higher than 253. Services which are intended for home-use-only, could insist on a minimum TTL of 254, and I'd be protected against any kind of bullshit coming from outside.
The same thing is true at work: I've got servers here which provide services, services which are never intended to be used from out of building. Yes, sure, there's a firewall dealing with that. But those can have bugs of their own, and are frequently misconfigured. This would be a useful additional layer.