It would be saddening if my response to your request for more information provided the reason why you aren’t going to address this real and widespread problem.
The thing is, I don’t need this feature myself. I’ve been using RTSP for decades now, but purely inside the LAN, so the NAT problem doesn’t affect me. I was responding only to give you more detail about the scope of the problem and to give you a possible solution to it.
I was surprised to be pointed at a conntrack module for this. I haven’t dug into its code, but I suspect it can cover only a subset of the cases. Again, RTSP is complicated enough that complete handling requires more code than is appropriate for a kernel module. What I can’t answer for you is whether that subset covers a large enough proportion of those wanting this feature to be worth integrating that kernel module anyway. It may well be a case of “good enough is good enough.”
Up-thread, we see people using the acryonym “ALG”, which I assume means “application level gateway”, another name for a proxy on a layer 7 service. If that read is correct, some of MikroTik’s competitors are solving this with one of these userspace level proxies.
This is not a niche corner case. RTSP is an old, well-established Internet standard protocol, with RFCs and everything. It is being eclipsed by the likes of HLS and simple HTTP download-and-playback type “streaming”, but it will only dwindle on the time scale of infrastructure replacement. I don’t need to lecture MikroTik about how long it takes to turn whole infrastructures over, now do I? 
RTSP proxy will not be able to solve the NAT problem anyway.
Sure it can. Firewall rules redirect the outbound RTSP requests to the proxy, the proxy on the gateway makes the media request, then forwards the replies back to the client that originally asked for them.
The only question in my mind is whether the more lightweight conntrack method suffices for a sufficient percentage of real-world cases as to be good enough to not bother solving the full complexity that is RTSP and its associated file formats and protocols.
there must be a very good reason why after 15 years it is still not a part of the Linux kernel.
Linux is largely driven by big business’s needs these days, not by random end users. Which big business would be served by making it easier for people to consume their media the way they want to?
Now ask this: which collection of big businesses have a deep and broad history of preventing every little technological advance in consumption convenience until they work out a way to lock it down first?
I do not suggest that RTSP proxying/NAT conntracking is any useful step toward movie piracy or anything like that, but to show that the companies poised to be the biggest advocates in this problem space instead have a vested interest in maintaining their closed systems. Why would they help anyone escape them, no matter how legal the use case?
The same goes for the IP cam people: every one of the big companies either sells a security appliance or partners with companies that provide them. If a NAT gateway in the middle of the LAN breaks that appliance, that means the company can sell two appliances! Again, why would the company advocate for getting an RTSP conntracking module into the kernel?
And the same goes for the likes of AirPlay receivers: Apple wants you to buy another HomePod and connect to it through their $/month cloud service, not redirect the RTSP stream through a NAT to play back on a Raspberry Pi.
This sort of problem is right in line with MikroTik’s mission: someone set up an annoying barrier, and we need technology that will help us to build a bridge over it.
