I'm curious to know why you need to change colors often enough for this to be an issue.
It's not as much about frequency of modification, as it is about retaining consistency across multiple different color categories as part of theme design/editing. Without the ability to persist colors, the only way to ensure consistent colors across entries is to actually write their values down (which is pretty ridiculous, and error-prone). Text editor customers generally prefer greater quantity of additional color themes available, so a design choice which explicitly inconveniences color theme creation effectively puts SE at a disadvantage in that regard, regardless of color-editing frequency.
Here's an example: Try changing a theme's background and embedded-background colors (consistently) for "Documentation Attribute","Documentation Attribute Value", "Documentation Comment", "Documentation Keyword", and "Documentation Punctuation" color entries. Because there's no common inheritance in sub-category groups like that, all entries have to be manually changed in order to achieve a consistent background & embedded-background appearance. Because there's no way to store custom colors between color entries, using custom colors for such repeated entries requires some form of "offline" storage for the colors. At best cut&paste appears to require three separate operations (for R,G, and B), as I wasn't able to drag&drop actual colors onto the color display (also would be useful, but that definitely IS a feature request).
I'd accept a change to have groups of symbol coloring sub-categories inherit their backgrounds/embedded-backgrounds from a common ancestor as an alternative, and believe that's needed long-term regardless, but doing so won't really remove the need for persistent custom color storage.
There's no shortage of solid arguments for why the ability to persistently store custom colors are useful, and the fact that most OS color pickers support that functionality only further supports that point. Even text-centric apps like SE, other text editors, word processors, etc. offer multiple UX scenarios where arbitrary, repetitive color selection is needed (as I've shown, w.r.t. SE), so it is simply flawed logic to believe persistent color selections aren't useful in text-based applications.
BTW, it's also worth noting that SE's color picker provides much poorer UX "accessibility" support than the native macOS color picker, a further demonstration why app developers shouldn't "reinvent the wheel" w.r.t. basic OS services/features unless they are
certain they can offer an equal or superior version (or at least offer the native option as a fallback). I'll report the accessibility issues in a separate bug post.