I have to disagree. In my experience, the frameworks get me to 80% completion but I'm not spending the next 20% on achieving completion. I'm spending orders of magnitude more than that fighting the framework, trying to make it function the way my product needs to function.
In other words, all of the time saved to get to 80% is lost, and then some, because the framework can't do what my project needs.
I've seen this time and time again, with every framework I have ever used.
I've used Ember.js in the past and must admit that it got in the way and the whole team was magnitudes slower than it should be, although I would also see the bad codebase we had to build upon was a big factor of this, so I can relate to that.
But I've never experienced this problem on projects where I'm able to choose my tools. I use Django and Vue.js with webpack and I can estimate the time constraints for each feature accurately using that stack which is most important for me.
Maybe you've used too opinionated frameworks in the past. If that is the case, loosely coupled frameworks like ampersand.js or very flexible solutions like Vue.js will be a pleasure for you.
In regards to the Pareto Principle: The 80/20 rule means that you need 80% of your time to finish those 20% outside the scope of your framework, not 20%, so your observation fits with this.
It's more like spending 20% of the time on 80% of the features (the standard ones), then 80% of the time on 20% of the features (the details, hard stuff and integration).
In other words, all of the time saved to get to 80% is lost, and then some, because the framework can't do what my project needs.
I've seen this time and time again, with every framework I have ever used.