Lets explore the Pros of SAFe as I see them. In a future article would look at the cons 

The biggest benefit of adopting SAFe is the opportunity to tap into a relatively lightweight framework that creates efficiency in software development while maintaining the centralized decision-making necessary at the enterprise level. 

Pros

In large organisations with multiple teams and vendors spread across locations, this is far from reality. SAFe has an excellent way of ensuring the teams recognise the dependencies (during PI Planning), discuss and negotiate them, visualise them and plan for them. 

SAFe is a solid way of engaging Business Stakeholders on a regular basis with the teams. SAFe's PI Planning process (and other mechanisms like PI System Demo, Product Sync etc.) literally force the teams to engage the business stakeholders, customers and even vendors in the Planning process. 

Business to Business, Business to IT Alignment

SAFe events like PI Planning, Product Sync bring together the business stakeholders, the product development teams, shared services teams and enterprise architecture teams into one place. 

Business and IT - Joint Planning 

In SAFe, all the teams within a particular group (called an Agile Release Train) start and end their Sprints on the same day. This brings a degree of synchronicity, efficiency and predictability to the delivery across the group.

Implementation Roadmap

SAFe has a solid, well proven Implementation Roadmap. This is something that SAFe has put together iteratively over many years drawing on experiences, lessons learned from hundreds of implementations.

Structuring the Teams

Many Agile teams do their best to deliver in a consistent, predictable way. But they are hampered because of the way the teams are structured and created. If Agile teams are created incorrectly - e.g. based on technology or component or location - they end up creating a huge number of Dependencies increasing the effort and the time to market.

SAFe has a lot of literature and best practices and strongly emphasises structuring the teams on a feature basis. The framework strongly recommends undertaking a Value Stream Mapping exercise (as part of the Implementation Roadmap) to structure the teams properly and efficiently (with an aim to delivering as independently as possible). 

Architecture and transition Design

Architecture and Architects are sensitive topics within the world of Agility with widely varying opinions in terms of their role in Agile teams.

SAFe tries to strike a sensible balance between completely centralised architecture vs completely de-centralised team based Architecture decisions for various reasons (in large organisations there could be a need to decide on certain tools centrally, purchase licenses on a global basis for certain applications / tools to optimise cost or decide on a central database decision etc.)

SAFe's mantra is - Intentional Architecture and transition Design. SAFe also appears to provide the right amount of balance between letting teams do their own thing but establishes some guard rails. It also encourages teams to think about architecture somewhat ahead of time with a continuous transition architecture.