Yes quite. How very witty of you. Too bad you aren't listening.
You only hear what you want to hear even though you don't know what you are talking about.
Your programming language isn't going to make you profitable. Your product is. Lucidity made the best point. The caliber of your programmers will make all the difference on whether you go from coding to selling on time and under budget with a working product.
Fatbat, you're a hell of a designer but I don't think you understand software development. Imagine if you had to design all your shit with MS Paint. The tools you use can make a huge difference. Programming languages and their frameworks are just tools.
A company like MS doesn't spend all their energy, money and resources having some of the brightest minds in the industry work on a framework like .NET just so at the end of the day they can trick people through marketing to believe it actually makes enterprises more productive.
Frameworks like .NET are designed to make enterprises more productive, which obviously is a key factor in profitability.
Also, the time spent on development before the first release of an app can end up being less than the time spent after that point. For most of the stuff most of us wickedfire people will do, maintainability isn't and won't be a big issue. But for bigger, more complicated applications, the maintainability and flexibility of the design is one of the biggest considerations. And the framework and even language plays a big part in that.
If you're a lone programmer or small group of programmers the "use what you know" thing applies more. But what if you're not a programmer and you're just hiring programmers? What that one programmer or groups of programmers know is of less consequence than what the wider world of programmers know.
What I'm getting at is, yes, everyone and their brother these days knows PHP, but if you want to do something really significant, you probably want to use an object oriented framework with an extensible library. A framework like .NET comes with this out of the box, with some really nice "real" object oriented languages to go with it.
With PHP, there is not a standard framework. Everybody has their own idea of what the best third party framework is to build PHP code on is. This makes things more complicated because now you have to choose a framework, which is a job in and of itself. And what if in the future, for whatever reason, you want to move the development to another shop or group of programmers? If you've developed in .NET the framework will probably present less of a problem. Where within the framework-segmented population of PHP developers you will have to find another group of programmers that has the same or better knowledge with that particular third party framework.
Not only is ridder's question valid, but if developing a big app with multiple programmers that will go on for years, it's not only a valid question but maybe the most important one.
The biggest danger is deciding that an app actually requires "good" coding when it doesn't, and then wasting time and money investing in best practices and tools that you'll never really get a return on.
For most of the stuff most of us at wickedfire would ever want to do, "bad" code is the way to go. That means you don't have to worry too much about what framework you use, you don't even really need to use one. You don't have to worry about doing proper OOP, using design patterns or using complicated abstraction layers. Portability and interoperability are still concerns though, and PHP shines there.