Possibly why you're having such an issue with "why" both RD and RT, you're working with very simple lab situations. The other posters have noted how in the "real world", scaling up creates issues not seen in a small lab example. Also, many small labs don't show the full capability of an architecture regarding how it might be used logically.
For example, have you ever studied the history of MPLS, and how it started as "tag" switching? If you have, do you understand the (back then, especially) performance implication of using "tags"?
I suspect some of the same logic is "baked" into RDs, i.e. they can be very efficiently utilized versus RTs, likely the "why" behind what @Harold Ritter explains how RRs use RDs but not RTs.
Rather than trying to explain "why" both RD and RT, and why one value couldn't (always) be used in lieu of both, I've selected 3 additional articles on the subject.
In https://www.networkfuntimes.com/route-distinguishers-vs-route-targets-what-are-they-why-do-we-need-them-both/
We find:
Now, even after all that explanation, you might still be wondering: this is all very well and good, but why didn’t they just design all of this so that the RD and the RT was indeed the same number, and have one number serve both purposes? Or, why not just force the VRF name to be the same everywhere, and advertise the VRF name instead of this random RT number? All of this seems like a lot of nonsense.
And of course you’re correct, in that networking is mostly nonsense.
But to answer that question, let’s take the complexity up a notch – because it turns out that we can actually do some really clever things with route-target manipulation. For example, we can create more advanced topologies that send all site-to-site traffic via a firewall at a central hub site. Another example is that we can actually leak certain prefixes between VRFs, which means we can introduce a management VRF that has selective access to certain parts of our customer networks, giving us the ability to monitor and maintain devices we manage on their behalf!
Sort of what you're asking, correct?
The two additional reference, also overlap with the above, but often multiple explanations, on the same subject, can be extremely helpful when you cannot interactively ask questions to an instructor.
https://packetlife.net/blog/2013/jun/10/route-distinguishers-and-route-targets/
https://www.linkedin.com/pulse/difference-between-route-distinguisher-target-ivan-anti%C4%87
If you understand the above, you'll likely recognize the potential of RT, but still wonder, do we really need the RD too?
Well, logically, possibly not. We do want, though, a simple and efficient way to identify different IP domains so that we can overlap IP network usage, i.e. the basic VLAN ID equivalent. The requirement for that, though, even if met by using a "reserved" RT, might also be "safer" if dedicated for just that purpose. Sometimes too much functional overload, can create its own set of issues.
Laugh - consider Classful addressing. Why do we need both an IP and a network mask? We don't, we'll just "reserve" ranges of IPs which will have implied network masks.
Likewise, not to repeat a similar approach, we have a RD just dedicated for route uniqueness, and RT for determining what's actually in a VRF domain. Often we don't need both, and many simple examples demonstrate you don't need both, but having them separate also allows us to process them separately without conflicts.
Hopefully, the forgoing, and the articles I referenced, will at least make in clear, having both an RD and RT, makes some VRF issues much easier to deal with, rather than using one common for both.
