You're messing up the syntax, but it's not exactly your fault: you're sending a String parameter, but it takes a Map. There is no way to create a parameter of type Map with Rule Machine at the moment. I worked around this in one of my drivers by making the underlying implementation of this command take either a Map or a JSON-formatted String with the same information (easy to convert to/from in Groovy/Hubitat), but I'm guessing most drivers don't do that, and that was mostly a workaround for me so I could test it from the device detail page before it allowed multiple color inputs. That itself is a relatively new feature, and the presetColor() command itself isn't even "standardized" (part of any defined Hubitat capability) yet, so I suppose we can't expect many guarantees at the moment--though the Map implementation does seem to be the convention and is analogous with setColor() (which is possible to do via Rule Machine, but only with the built-in actions; you'll run into the same problem if you try a custom command).
This would be possible with a custom app, but it would also be a possible Rule Machine enhancement to add this type of parameter (probably less likely given how complex the UI would need to be to make it work, but who knows...) or a "real" action to do a Preset Color (maybe more likely, though, again, it's not a standardized command yet)--or, perhaps, a modification of the driver to accept some other format you can do, like JSON map (maybe even less likely and more of a workaround, though it is possible to write custom LIFX drivers using the same interfaces the built-in drivers do).
But as-is, there are not any immediately-available solutions I can think of...
"Set Color" will turn the device on (if it's not already), besides setting the color. This is analogous with the "Set Level," "Set Color Temperature," and similar commands. "Preset Level" was recently added as a way to pre-stage the level without actually turning the device on, and it was standardized into a capability that drivers can use and apps can expect a uniform implementation of. "Preset Color" is the same idea but for color; it's just not (yet?) standardized into a capability. These are all alternatives to a different approach some older drivers used of a preference to "pre-stage" things, which affected the way standard commands worked (like "Set Color" or "Set Level") and was all-around less desirable because apps (and lots of users...) never knew what to expect.
tl;dr they have different uses and it appears the OP wants this one
I'd say that is an "it depends" statement. We had this same discussion around my attempt to do the same thing (adjust color without turning on the device). The tl;dr was that, at least with the "generic RGB component driver", if I used "set color" and just left the "level" option blank, it would essentially prestage the color change.
If leaving the level key out of the color map makes the bulb not turn on, that is more or less just an accident that could be considered a happy accident if that happens to be the behavior you want. Standard behavior for all level-, color-, and color-temperature-related commands in Hubitat is to turn the device on if it's off. (This is part of the reason why the "legacy" prestating preferences that altered the behavior of the standard commands were/are such a pain and why the new standard command[s] are, IMHO, a much better approach. It's also why I wish we'd have more standardized than just level at this point...)
Some drivers may just throw an error if all components of the color (HSB/HSV) are not specified. In this particular case:
It depends what model you have, but with the LIFX Legacy Color driver Hubitat has published as an example, it looks like it will default to 100 for level if you don't specify one yourself. It's possible this isn't the code that made it into production since it also uses a prestaging preference instead of a command, but in any case, it's yet a third possibility for what could happen.