I hear that strong preference on including data as an object. I also ask you to consider the performance / complexity tradeoff. If it was limited to hex RGB, this would be fine. But component rgb....
First up, usability:
Hex RGB is definitely the standard here. Almost every UI platform supports '#4488ff'. Putting it into components makes for extra work for the developer on the way in and the way out.
Let's presume we limit the syntax to hex rgb for the next bit: data transmission:
"red" + "green" + "blue" is an extra 12 bytes right there. shorten it to RGB and you take that down to 3 bytes, but then you the quoting around keys to worry about, plus the colon (9 more bytes).
That's more "over the wire" than required, by far. As written, 21-26 bytes to send the data, versus 7. That would be sent across the jetstream and duplicated into every pds. Surely that's nothing compare to text posts, but it also adds up.
I'm a big fan of "as simple and open as possible" lexicons, so I think just suggesting css color and taking a single value the right long term answer here, because it has a whole standards committee behind it and support from almost every web based UI framework.
But if we want to keep it "very standard", I'd still think HexRGB should be the default, and component RGB would be the exception.
If we want it to be very fast, then standardizing on a uint32 representation of RBG or RGBA would be quicker (and roughly the same amount over the wire, depending on the color used).
If we're finding the sweet spot between usability and insanity, hex color.
If we're being as long term open as possible without taxing the developer, css color
If we want the developer to pay a tax each time they use the color, keep it in pure component form.
(apologies for the strong feelings here - been doing graphics work long enough to know how important simple choices like these can be on framework adoption )