Example: I'm working on a "large" CakePHP application (similar to Rails) with 24,000 lines of our own code, 57,000 lines of code from community plugins, and 240,000 lines of core framework code.
That does include all of their unit tests code though. I wouldn't personally define unit tests as "core" framework code since I can deploy a Rails app without them (they never show up in a stack trace). It's going to come down to your own semantics since Rails wouldn't exist as it is today without them either.
Ahhh, you know what? I just realized I was confused: the diff for rails 4 was about +110,000 / -100,000, that's what I'm remembering that number from. My bad!
If you are saying the size of your application could be reduced by rewriting it to using a framework (an existing one or one of your own creation), I think this is the point we are all trying to make here.
Assuming one uses all the features of a framework, the total complexity of my 24K line framework application (counting only code I've written) could be compared to that of a 321K line non-framework application (counting all the code in my project).
Thankfully I only have to write/maintain 8% of the codebase, as the remaining 92% is kept up-to-date by typing `composer update` on a weekly basis.
In this case, simply refactoring to remove duplication would probably work. For example there are at least 3 different ways to send email.
There is a lot of code in there that is really "framework" but it's completely baked into everything else so not really separable. There's probably at least 2 different and distinct attempts at creating a framework, and you can tell the age of the code by which it uses.
The main reason it hasn't been significantly refactored is that it is astonishingly reliable considering how bad the code is.