This is going to get down into the weeds a little bit, so bear with me. I put the key info in bold.
As you see, there are two ways to update an Item, four if you include sendCommand. Lets just focus on postUpdate for now. This all also applies for the difference between sendCommand and item.sendCommand.
The code in openHAB is Object Oriented (OO). In an OO language you have these things called Classes. A Class is a definition for collection of data and methods that operate on that data. When your program is running, an instance of a Class (i.e. a bundle with actual values for the data and functions to operate on that data) it is called an Object.
So the definition of the Class Item lists all the data and methods you can call on an Item Object. In your code, MyItem is an Object, an instance of the Item Class.
There is one powerful feature of OO languages and that is inheritance. With Inheritance you can create a parent Class (e.g. Item) which defines a bunch of generic things. Then you can create a sub-Class (e.g. Switch) which gets all the stuff from the Item class plus the opportunity to create some new data, members, or the ability to change the behavior of some of the methods the Item Class defined.
With Inheritance you can then in your code treat a Switch as if it were an Item which then lets you write code that doesn’t have to care about the difference between a Switch, a Contact, a Dimmer, etc. This is what the Rules Domain Specific Language (DSL) does, it treats all your Items as if they are Item objects.
All of that is background. The key piece of information is the line I bolded above. When the coders created the Switch, Contact, Dimmer, etc Classes, they wrote their own version of the postUpdate method customized for that particular Class. So when you call MySwitchItem.postUpdate(newState) on it runs different code than when you call MyDimmerItem.postUpdate(newState). And this different code can be smart and flexible in converting newState from various different Classes (e.g Strings, ints, OnOffType, etc.) into the specific type of Class the Item needs (e.g. Switch needs an OnOffType).
The postUpdate Action on the other hand is completely generic and has to work for all Item Classes. Consequently it is not able to be as smart about handling converting between random types that you might pass to it and the State Class the Item needs.** So the developers created only one postUpdate action that accepts two Strings, one that is the Item name and the second which is a String version of the new State.** The Rules DSL will sometimes hide this fact from you by automatically converting things to a String for you, but it isn’t always able to do that (e.g. when you try to pass a primitive int or float as the new State).
Therefore, because the Item.postUpdate method can be smarter and more flexible about converting stuff passed to it to the needed State I always recommend using Item.postUpdate wherever possible.
here is something that works every time: