It's easy for conversations on Agile methodologies to quickly turn into religious debates, to which everyone has an opinion, and the reason for that is that adopting a methodology wholesale very rarely works for everyone. Very similar to the reason why adopting the Spotify model for every organisation very rarely works. Adopting anything wholesale is devoid of context of the business, the industry, the teams and the individuals.
I'd rather us look at the problems we're trying to solve and focus in on them with a beginners mindset and one of experimentation, trial and error, inspect and adapt. That way we will end up with what works for us without focussing on the solution alone (the adoption of a methodology). A question I like to ask when people advocate wholesale for SAFe is, why SAFe and not DAD (Disciplined Agile Delivery) or LeSS (Large-Scaled Scrum)? My point here being that do we really know why we're adopting this particular methodology and instead try and drill into the problems we're trying to solve first before focussing on the (possible) solution.
I find SAFe is often adopted in an attempt to put process and control around teams and is rarely advocated by the teams themselves, particularly engineers. Of course there are benefits to some amount of process, my point isn't about having no process at all. I've written my thoughts on process adoption here http://ryantomlinson.com/the-process-delusion/. My point here is that the focus shouldn't be on coordinating dependencies between teams but instead reducing the number of dependencies by realigning the teams and products, resulting in greater autonomy between teams. There's a great tweet this week by Allen Holub on a similar point:
"Agility at scale" is nuts. Scale the work down, not the process up. I've never seen an Agile process that was "scaled up" retain its agility. Can very large systems be built in an agile way? Sure. Should they be? Probably not. Build smaller cooperative systems instead. https://twitter.com/allenholub/status/1083845056346243072
A methodology can sometimes be good as a starting point but as with all systems we should inspect, adapt and iterate given our context and our shared learnings and failures.