Presets are defined by the integration. As implemented there is no requirement for them to be case insensitive. I do believe that they could be case insensitive and that would be better for the product, such that if you specify Away, away, AWAY, AWay you get the same result. That said, unless you want to create the pull request that changes this for 100+ integrations, it probably won’t get changed. You could create a GitHub issue maybe some one will pick it up.
The workaround is to do two service calls in a row, one for the thermostats that use “away” and the second for ones that use “Away”
Regarding the automation editor. I don’t use it. But a reasonable implementation would be for the drop-down to only show preset modes that are common between all the targeted entities. Since yours all have different cases there is no common set.
The HA frontend translates state values into “pretty” versions, this includes capitalisation and has confused a lot of people but the developers are not going to change it back to the real value. The only way to see the real value is to look in Developer Tools → States.