Empirically, all regressions still pass. :-)
It might be easier to explain why it was ever necessary, which is definitely before my time with gem5.  This check was introduced in 2011 (3893d9d) with the comment "make sure fetch doesn't go off into the weeds during speculation".  This check is unrealistic and now o3 doesn't have any issues because it can handle whatever faults come from bad fetch requests, as it should.

I agree that this check is unrealistic, but "all regressions still pass" is (unfortunately) pretty far from a validation that the check is unnecessary. When you're misspeculating in kernel mode, and there's a TLB-bypass portion of the address space, you can end up fetching from just about anywhere (invalid physical addresses, I/O space, etc.). It would be ideal if we could tolerate all of these things properly in the memory system, but I'd feel a lot better if we knew exactly what circumstances prompted Ali to put this in there in the first place, and knew for a fact that that specific issue was now handled properly otherwise---the software application of Chesterton's Fence (https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence ).

The issue was some mis-speculation that invoved trying to fetch instructions from an I/O device. If we remove this check then I think we need the reverse of addresses to stop fetch from reading. 
Unfortutantly, it's not as simple as only reading from cacheable addresses since typically during boot there are phases in which addresses aren't cacheable.