At the risk of being wrong (it happens a lot) I think what is going on is that the postUpdate action has to be generic enough to handle ALL Item types. So when you use the action it has a plethora of different types of State objects it needs to cast the value you pass to it into in order to update the Item. And if it works like the MQTT binding did (until recently, thanks@watou!, still no errors on my end) it ends up matching with the first type it can be cast to which may not always be the right type for the Item.
But, when you use the postUpdate method on the Item itself it knows a whole lot more about what sorts of States are acceptable and how to cast and convert between them so it handles the state better.
I’ve seen this both in my rules and in others posted on the forum and it is the main reason why I almost always use MyItem.postUpdate and MyItem.sendCommand instead of the actions. And when I do need to use the actions I convert the State to a String.
If I were implementing something like this from scratch, the action methods would turn around and end up calling the Item’s postUpdate or sendCommand anyway. That would consolidate the code so the behavior would be the same. But having not looked at the code I’m sure there is some limitation or other reason to not do it like that.