I'd say that the main thrust of my argument could be summarized as "frameworks are good, you should use them to write apps." My observation is that often when people say they don't want to use a framework, they end up trying to write code that does similar things the framework would do, but because they're not experts in designing frameworks, they do a bad job of it. An example would be rather than using an ORM, people write some one-off database service, and then copy-and-paste and find-replace to write another one. This leads to a great deal of code duplication, and makes it difficult to fix bugs and fix performance issues (e.g., to implement a read-through cache, you'd have to go through each copy-pasted variant and implement the cache, rather than implementing it once in a base class.)
It's not that these people are writing a better framework that adapts more to their needs, it's that they read on the internet "don't use frameworks" and decided they were smarter than all those other startups that use Rails. The result is generally a pile of half-complete, poorly-conceived ideas centered around decisions that no longer make a lot of sense.
I say all this having used, seen and maintained many a homegrown framework in my time as a contract developer. I'm sure they're out there, but I've never seen a codebase that doesn't use a pre-existing framework that's better than one that does. I think if you work on a small team, it is very difficult to take the time to write a well-designed and well-tested framework in addition to your main responsibility, which is presumably to make features that users are dying to give you money to use.
You are definitely right that you can paint yourself into a corner with frameworks. I suppose my theory is that as long as you're using an open-source framework, you will always be able to code your way out of whatever situation you end up in. I also believe (but obviously cannot prove) that in nearly all of these situations, the net effect of using a framework will be a positive in terms of both your code quality and your productivity. It goes without saying that if you choose to use a crappy framework, then you're going to have problems.
To be really clear -- I didn't write "don't use frameworks".
I will happily say "Don't use megaframeworks; use microframeworks.". And, I'll add "read the code in these microframeworks, learn what they do and how they do it, and start to see ways that the different tools available to you can be assembled".
I also absolutely agree that one should not create your own (mega)framework in order to build your application. But luckily I never said that one should ;)
And, I agree with your last paragraph and can add to it: "I suppose my theory is that as long as you're using an open-source framework or collection of microframeworks,..."
In my own experience, over time the use of small, clean open-source libraries (the microframeworks) beats the hell out of the codebases built on the megaframeworks. Eventually, you have to replace something, and replacing one component among many is a hell of a lot quicker, easier, and efficient than plumbing one out of a larger, less simple, monolith.
It's not that these people are writing a better framework that adapts more to their needs, it's that they read on the internet "don't use frameworks" and decided they were smarter than all those other startups that use Rails. The result is generally a pile of half-complete, poorly-conceived ideas centered around decisions that no longer make a lot of sense.
I say all this having used, seen and maintained many a homegrown framework in my time as a contract developer. I'm sure they're out there, but I've never seen a codebase that doesn't use a pre-existing framework that's better than one that does. I think if you work on a small team, it is very difficult to take the time to write a well-designed and well-tested framework in addition to your main responsibility, which is presumably to make features that users are dying to give you money to use.
You are definitely right that you can paint yourself into a corner with frameworks. I suppose my theory is that as long as you're using an open-source framework, you will always be able to code your way out of whatever situation you end up in. I also believe (but obviously cannot prove) that in nearly all of these situations, the net effect of using a framework will be a positive in terms of both your code quality and your productivity. It goes without saying that if you choose to use a crappy framework, then you're going to have problems.