of course it works... it just limits sending CC messages to the time you specify.
the issue is, because the float value is constantly changing, it will still be sending a stream of CC messages, even though the cc value is not altered.
e.g. imagine you set the throttle time to 1 second, and that the gpio is jittering around, 0.4999005 and 0.500005.
what will happen is you will be sending CC of value 64 every second, because the float value is jittering around 0.5, not enough to kill the system, but still a waste of resources/io
now if you quantise to 128, ( using a simple shift followed by a bit mask) , the result will constantly be 64 - so the change never triggers, as the (quantised) value has not altered. so no CC are sent saving cpu and io.
it doesn't actually matter if midi/out/cc supports integer of not! you can use your calculation for the trig condition... regardless of what is sent to the value.
that is why the trig is separate it allows the patcher to decide on the criteria of when to send updates - as there are a number of potential strategies depending on what is required.
anyway, this is why when working with midi, id always recommend monitoring the input/output when testing , either internally on Axoloti (midi/utils/monitor) or even better using a monitor app.
tip: if you have 2 Axoloti you can use one as a midi monitoring device ... use my thru object, and put the test axo in between patch tested, and device... if the midi light blinks like fury, or when you don't expect, then you know you have to take a closer look at the messages sent