I'm still new to using SXA so take my opinion with a grain of salt. I will provide some examples to explain my position.
What I can say is that there are enough benefits to using SXA that I would recommend it but I can't say it's all green grass and rose petals. There's quite a learning curve as it relies a lot on SPE to create many things which aren't obvious to find if you need to serialize it all with TDS. It also introduces a number of new concepts and moves many things to the content section of the tree which makes it confusing what to serialize and what not to.
On the up side, it fixes a lot of odd behavior that comes with a stock installation of Sitecore such as managing multisite systems, duplicating content trees properly, providing easy access to placeholder settings, easier domain configuration and having a page local or site global datasource folder. It even has a concept of reusable page chunks (header, footer, nav) which I did't realize how much I needed until I had it. All of these things make it worth the using over building it yourself.
I think the biggest mental paradigm shift for me is with what components you're provided and how they are rendered. I'm not in love with everything about it because of the trade offs made but there's still a lot of good ideas that push you past any capability you use to have.
One such example is that components are no longer just a rendering item pointing to a razor file or controller method. They are now modules with a scaffolding infrastructure. On the one hand it's a lot of extra. On the other hand much of it is managed by SPE commands and is easy to add groups of components to one or many of your sites consistently.
Another new concept is rendering variants. On the one hand you need to manage your markup as content items, which every front end developer I've worked with has hated with burning passion. It creates a strange relationship with your razor file that makes it much more difficult to know how to handle many aspects of a interactive components (as opposed to just a visual component). There's even a complex decision tree to help decide which way to go. On the other hand it's an interesting idea that you can select different formations of a single component and it basically eliminates all of the time spent trying to get your dependency injection and model generation working with experience editor fields.
One of the most troublesome parts of it is how our front end developers lives changed with it. I didn't have a great experience as others seem to have had or is the intended process. We have very experienced front end developers who take on the role of building search friendly, accessible, responsive pages. They're used to controlling the structure, tooling and functionality. Typically they construct all the markup and style at once and back end developers would apply experience editing capabilities. With SXA the markup is divorced from the styles and either the front end devs have to do markup in the content tree or someone else with much less experience does it. Then the front end devs only job becomes a paint by numbers task. This task requires them to connect to the media library to modify the js and css files through a sync gulp task which isn't too bad but they are then given whatever framework was selected when the site was created which they don't control. This is where the most challenge of acceptance comes from with my coworkers. If this process worked better for the front end developer workflow it would pretty much be the undisputed best option. For now though it is less than ideal.
