Frameworks are also good in a long run. When a new member on the team starts to work on a project, it is much easier to pick up on some popular framework like Rails than your own one. First, because you can easily find a guy who worked with Rails framework and knows it inside out, unlike yours custom-written one. Second, the whole infrastructure, like regular updates, documentation and community is also a major factor.
Having worked professionally for several companies who had 8 to 10 year old proprietary code bases, I'm a big fan of using frameworks for web development.
If a company isn't going to use a framework, they had better architect and spec out their app with heavy documentation. I would argue this is more for the stability and future of the app and company than it is for ease of hiring purposes.
Without a spec or framework, you run the risk of ending up with various styles of code (often times some really terrible stuff) sprinkled throughout the codebase, constant arguments between devs (as there is no established standard within the code) and a mountain of "tech debt".
> because you can easily find a guy who worked with Rails framework and knows it inside out
That's only relevent when you are hiring someone to deal with the monstrosity of a rails app that you ended up with because the abstractions didn't quite work for the problem you were trying to solve.
I've found it very easy to use some Rails best practices in a Sinatra app and not have to deal with all the routing/controller cruft in Rails, while still getting sensible filesystem conventions.
