I have seen high performing software organizations that use SAFe, although I am not at liberty to name names. The keys are to have senior leaders that are really committed to it (not just lip service) and ignore the parts that aren't helpful for your particular circumstances. Pretty much everything in SAFe is optional so you can pick and choose the parts that you want (although if you decide to ignore or customize some parts then you should at least have a clear reason for doing so beyond a belief that your organization is somehow "special").

FAANGs operate at mega scale and have the luxury of enough time and resources to create customized methodologies which ideally suit their unique circumstances. But most software organizations can't afford to hire experts to build up custom methodologies (or they wouldn't know whom to hire even if they could afford it). The benefit of something like SAFe is that it's "good enough" for less sophisticated organizations to adopt off the shelf and move forward. And if you look inside the FAANGs you'll see that they essentially do follow many parts of SAFe although they tend to call things by different names and hide some of the gory details from lower-level ICs.

I haven't done any federal government work but I've seen large government contractors successfully apply SAFe. They aren't making sprint plans more than 3 months in the future.

Again, SAFe isn't anything particularly wonderful. It's just a reasonable starting point that represents accumulated industry best practices for large enterprises with a lot of complex moving parts. Much of the criticism is simply uninformed. Anyone who wants to criticize it should at least cite the relevant section (everything is publicly documented) and explain why that part is unnecessary or suboptimal from an overall business perspective.