I looked into this for an audio app, and it looked really cool. Then I contacted him to find out what contingencies were in place because of the truck number of 1 (!!). I asked him if he had any business partner, or perhaps a dead man's agreement in place in the license by which if the company folded or he left it would revert to open source. Not only does he not, but he was a jerk about it, completely dismissive of it as a valid concern. No way would I put years of work into a project on a platform that might become stagnant because of his lack of foresight or understanding there. So I just used QT and other audio only toolkits. Pity, it's really neat looking.
As is so often the case, IMHO the poster is ignoring the business side of the equation in favour of "correct". A good ORM is fantastic for speeding up development. If you design your db around being well usable with the ORM, the potential development gains (at least in dynamic languages like Python) are HUGE. I left Django in part because of their ORM. But using SQLAlchemy, we develop far, far, faster than if we were using SQL directly. And it's flexible enough to allow me to drop into the SQLAlchemy Query language when I need to hand tune a query, or to SQL itself if I really need to get close to the metal.
Will there be downsides one day? Probably. Will they come even close to the business value of the amount of the coding time we've saved during the critical bootstrap phase? No way in hell. As they say, those are problems I'd love to have.
Further to this, as fallible humans, we usually get the design wrong on the first try. The truly multi-paradigm nature of python has for me made it a really great language for refactoring and iteratively arriving on a good design. You can write proto-types really fast, and turn them into more formal architectures very smoothly.
For me, Python is the only language that addresses the human side of programming well. You just plain make fewer mistakes with Python, and it's way easier to reload code into your brain after not looking at it for a while. The readability and obvious syntax has vastly more far reaching effects than one thinks it will when first learning it. It's amazing how much more productive one is in a language that is easy to read, easy to type, and easy to figure out what the most likely way to do something is. I reach for pdb more than a manual because most of the time I can guess what an api will be, and if not, 5 seconds of introspection reveals it. Ruby is well designed for computers, but Python is better designed for us fallible humans who have to type into computers. ;-)
I would add that the data mapper pattern gives you very fine grained control over what objects and attributes of the object are matched to which tables. So refactoring either your object layer or your table layer is easy to do independently.
I agree with that assessment with the exception of the repoze.who comment. Repoze.who is bad ass. It takes a while to get your head around it, but at the end, it is far and away the best engineered and extensible auth system for python apps. I would encourage you to take a closer look.
To be fair, I should point out that it's much easier to get new developers going on Django, and that the monolithic approach gives people a much better out-of-box experience. Just not my thing, I like Vim better than Eclipse too. ;-)
I've use Django, Pylongs, TG, and repoze.bfg. It's quite different. A vastly oversimplified metaphor would be unix to OSX. Django is a monolithic all in one environment where everything 'just works' together but is not useful outside of Django, and no part really really excels at its own job, while being good enough for Django. Pylons expects you to write a lot more glue, and works better if you anticipate hitting the wall with a Django component ( ie Django's ORM is not even close to SQLAlchemy ). Pylons tends to attract people who will be writing a complex app that they will run with for a long time, or be extending in their own way. If you think there is a good chance you might need to rip out own component to replace it with a tweaked one, or different version, it's a lot easier with Pylons. Pylons is also written from the ground up around WSGI, so if building app stacks out of WSGI is your thing, that is still easier in Pylons ( though possible in Django. It still feels a bit bolted on though ).
That said, I personally prefer repoze.bfg over all of them now. Also minimal, built on wsgi, but also built on the Zope Component Architecture ( just the ZCA, does not depend on the ZODB or Zope server). For really being able to reuse and extend your code, that ZCA infrastructure is the killer feature.
This is totally true, with one giant caveat: how much you are worth will not sell itself. You will get referrals, but you need to make sure that you are negotiating properly or you can wind up swamped with work that you aren't charging enough for. Sooo, even if you feel like you have all the work you need, you owe it to yourself to do some sales reading. ;-)
I'm a freelancer in web dev and show biz and have done a lot of sales in that area. Brian Tracey's "Advanced Selling Strategies" is probably the best single book out there for individual one-on-one selling, especially if you also read "How to Win Friends and Influence People" 80% of reviewers on Amazon gave it 5 stars, and the rest 4. That's saying something for a business book!
I would also highly recommend finding good books on negotiation too. Balancing relationship sales with negotiation and estimation is IMHO the hardest and most far-reaching aspect of being a freelance web dev.
For a self taught programmer, I find it quite interesting to see which areas I've gotten up to 3 or 4 and which are 2. ( Thankfully none are lower! ) Though obviously it's going to come from one industry bias, it's still useful as a reminder of what areas I should do more reading in.