My first response is that Apex is the best way to talk to the Force.com environment. The Apex language and its engine can be aware of the application space, and can protect the developer from many potential misbehaviors in a way that a non-specific language would have to be heavily instrumented to match. You could do that — you could create all that design-time and run-time protective support, I mean, in PHP or whatever — but what’s the point?

I’m reminded of Paul Graham’s comment (in an excellent essay entitled “Revenge of the Nerds {http://www.paulgraham.com/icad.html}) on what happens when you try to solve deep problems with shallow languages: to “build cathedrals with toothpicks,” as it’s often been called. Actually, Paul was citing “Greenspun’s Tenth Rule” (http://en.wikipedia.org/wiki/Greenspun’s_Tenth_Rule) when he reiterated that statement that “Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.”

The point is that good programmers take the best language that’s available on their target platform, and devise within that language a task-focused language suitable to their target problem. The closer you start to the end of step 2, the less time you have to spend on it and the sooner you start actually solving your problem. Implementation of patterns in that gap will be easier if the gap is smaller.
My second response is that it’s rare, any more, to see any useful application that’s written using tools that are not aligned with any specific platform. A Windows application written in pure ANSI C is still a Windows application, unless it’s just a TTY app that’s compiled to execute in a console window — not that there’s anything wrong with that, but it’s not what most users expect. In general, the user gets no additional freedom from an application’s being written in ANSI C, instead of (for example) C# or VB.Net. By the time the developer has effectively exploited the widgets and frameworks of any decent application environment, the question of what was used to stitch the API calls together is pretty much incidental to the question of how free the user is to employ the application as desired.

If an application needs a particular fat-client environment, it’s not a portable app, no matter how it’s coded; if it runs on any device with an Internet connection and a standards-conformant browser, it’s a portable app by any reasonably modern definition of the term.
When a language is suited to both the platform and the problem, design patterns can add value at a higher level of abstraction, and that’s a good thing. Putting powerful patterns on top of Apex is therefore a significant step toward the ever more general use of Force.com.