"I always have the question that whether the WRED cares about each traffic flow."
WRED no (per flow - FRED, yes per flow - latter I suspect not supported on Cat 9Ks - I recall only some Cat 4K sups supported FRED [Flow based RED]).
"Or does it only care about the DSCP values?"
Only, no, but DSCP values could be (depends on WRED configuration i.e. can be very important).
"One flow is significantly larger than the second. Would the switch calculate a higher drop probability on the packets with the larger flow? Would the end result be to throttle the larger flow more to give better chance for the small flow to go through?"
That's an it depends answer. I suspect how WRED works, or does what it does, is a bit unclear to you?
"I understand that this would only affect TCP flows and the drop only happens when congestion is happening (when the queue is being filled up)"
No (regarding TCP only) and no (only when being filled up).
I realize, at first glance, and with typical (W)RED documentation, it seems to be an outstanding congestion management solution (at least for TCP) and yet simple to use and configure.
(W)RED can be used for effective (TCP) congestion management, but getting it "right", within all its "quirks", is far, far from simple. So much so, I recommend QoS non-experts, don't use it at all, except perhaps configured to implement tiered tail drop.
On the subject of (W)RED, I often suggest search the Internet on the subject and, for example, take note of all the variants of RED, trying to "improve" it and/or correct some of its "quirks". Heck, even Dr. Floyd who first proposed RED, had an "improved" version not too long after.
One of REDs "quirks" is it might not drop any packets as a queue rapidly fills or it might drop packets, as they arrive, while the egress queue is empty. (If you wonder how this might happen, it's because RED uses an "average" queue size, not current queue size.)
Also, the nature of traffic, today, is often very different from what existed when RED was first proposed. Big difference managing FTP (then) using TCP, vs. HTTP/HTTPS (today) using TCP.
PS:
BTW, another difference between then and now, TCP depended on packets being dropped for flow rate management, but many modern TCP stacks also closely monitor RTT and slow their transmission rate if RTT suddenly increases.
Another then and now difference, that impacts RED, then hardware for "advanced decision" making was often rare, so a goal of RED was to be of light impact while routing packets (i.e. when T-1, 1.5Mbps, was "fast"). Today, hardware can do lots of "advanced decision" making, even when doing 100G, etc.
