There’s a few good reasons DRTV is a good fit for Unity:
Consider DRTV can be spread over a number of frames (Far cry 3 and assassins creed 4 do this, you can catch it out if you’re quick enough in a new area), it’s also a suitable fit for modern mobiles, particularly as you can bake the immediate area on the fly in a timely manner.
For a paper and further discussion you can check it out here:
As far as I can tell there really isn’t anything preventing the implementation of DRTV? I’m working on something similar, precomputed radiance transfer, which operates on a vertex level instead of in screen space. Since Unity does not allow custom vertex data I have to do it with DX11 and compute shaders. Is there some limit imposed by Unity that I am unaware of that prevents DRTV? I don’t own Unity pro so I’ve never really worked in screen space from Unity 
It’s simply a lot faster if Unity do it natively.
Mobile, OpenGL. It doesn’t and never has needed compute shaders. Those will make it faster but meaningless cross platform.
Unity will do a better job, especially with the light probes stuff.
I might be wrong but as far as I have understood Unity dont seem interested in providing tools for this/next generations graphics like UDK or CryEngine does. Dont get me wring, I would love to see it implemented, unfortunately I dont think its gonna happen : /
It’s still particularly relevant as simply abusing compute performance is foolish when it can be used for other tasks. This is a big problem, using new toys when the old toys give more bang for buck even with next gen. It means you can make bigger worlds and for all intents and purposes looks the same as new technique X.
Would you rather be using the GPU on liquids and fire or scene lighting? Why not have both. Granted, you could do both via compute, but at some point how much you’re doing with compute isn’t going to fly. I understand if it’s too much work though. Too much work is really why I ask for it 
True, I would have loved being able to use custom vertex data to store SH coefficients. Unity doesn’t allow that so I am working around it using compute shaders instead. I am not sure how much faster it would have been to do it “the proper way” instead, but so far performance doesn’t seem to be suffering. As far as I can see, Unity really has to decide between two different approaches and then go full heartedly for that approach. Those two approaches being implement graphical systems themselves, optimizing it and therefore leading to great tools but slightly limited in customization OR they can opt for as much customizability as possible and make everything exposed to the user allowing for almost perfect implementations. It seems like Unity is tilting towards the customizability side of things but there certainly are a few internal workings I’d love to have access too
This is a common theme with Unity and one I’ve had a bit of an issue with before - access to lower levels. But I suspect the reason they don’t isn’t really to shift source licenses, it’s just that for everything they expose, they have to offer support and make sure it works. So it actually is expensive for them to open up more lower level access in terms of support overall.
Having said that, it would be nice at least if graphically, we get more toys. The best way to achieve this is if the community constantly ask them for a feature to be exposed and give them a good case study why. This could be one good reason.