I agree with what you are saying. I love the idea of presets, but setting a default for the text inside "palette" might make sense, but hover and focus can be used in a variety of ways and may be impacted by block style. Hover color could be applied to border-color, background, text, etc and the block with a background color selected may not even need or want hover effects.

Text Color Default

Theme.json

"palette": {
    {
        "slug": "white",
        "color": "#FFF",
        "name": "White",
        "default": {
            "text": "darkGray"
        }
    },
    ...
}

Implementation: Develop a hook into the block color support and set the default text color if block support allows. Block supports already allow default attribute values for color. This would also allow for cascading and overriding in block settings in theme.json.

This would set the initial value and automatically apply .has-{color-slug}-color to the block. Then the user can override that default by selecting a new text color. I think this is a cleaner approach then adding color to the background-color class.

Hover/Focus Defaults

If hover/focus colors were included as a default setting, it would need to be included in block settings for those with "hover" support. It would be great if selecting certain block styles activated supports for different hover settings. For example, a button block would be a logical choice with hover color support, but hover color support would have nested support based on the style selected.

A theme could register an "Outline" button style and add nested hover support for background-color (think Material.io imitation hover "overlay" effect) or border-color. It would depend on the theme design for that particular style. This would require big changes to implement though. NOTE: Hover support does not currently exist nor does registering block styles with varying block supports. Block styles only add a style class at this time.

This was a big pain point when developing Twenty Twenty-One.
It is important that the users choice is still respected, even if the theme designer would disagree with their choice....

Perhaps there should a palette type called "color pairs"?

@carolinan I'd love to learn more about that. Are there specific tickets that would be helpful to review for understanding that history?

In my experience, so long as the background color classes are listed first and have the same or lower specificity as the text color classes, they don't interfere with user preferences. Handling all possible nesting scenarios does get more complicated but feels like it's probably still solvable.

Higher specificity via source order

.has-black-background-color {
    background-color: black;
    color: white;
}
.has-white-background-color {
    background-color: white;
    color: black;
}
.has-black-color {
    color: black;
}
.has-white-color {
    color: white;
}

Higher specificity via selector

.has-black-background-color {
    background-color: black;
    color: white;
}
:root .has-black-color {
    color: black;
}
.has-white-background-color {
    background-color: white;
    color: black;
}
:root .has-white-color {
    color: white;
}

The "color pairs:" idea would definitely be an improvement over the current state, though my concern would remain about added pain when switching themes.

In Twenty Twenty-One, the button is inverted on hover; the filled style is the hovered style for the outlined, and vice versa.
The default button color changes depending on the background.
By default, the button background is dark grey. If a button is placed in a group block with a dark grey background, the default button background is the mint green...

And then all that was reverted in dark mode...
https://core.trac.wordpress.org/ticket/51927