I wonder if the filtering algorithm is really as simplistic as the Timescale blog implies ("for every label/value pair, first find *every* possible series which matches; then take the intersection of the results")? I don't know, I'll leave others to answer that. If it had some internal stats so that it could start with the labels which match the fewest number of series, I'd expect it to do that; and the TSDB stats in the web interface suggests that it does.
I ask again: what version(s) of Prometheus are you running?
Are you experiencing this with all prometheus components, i.e. a prometheus front-end talking to prometheus back-ends with remote_read?
I think the ideal thing would be to narrow this down to a reproducible test case: either a particular pattern of remote_read queries which is performing badly at the backend, or a particular query sent to the front-end which is being sent to the backend in a suboptimal way (e.g. not including all possible label filters at once).
You said "for now we need a workaround". Is it not sufficient simply to remove {global_label="constant-value"} from your queries? After all, you're already thinking about removing this label at ingestion time, and if you do that, you won't be able to filter on it anyway.