There are two reasons:
1.  Startup applications are, by definition, new, or "green-field," projects: there are no old internal databases, code, infrastructure, business rules, or data center rules to deal with. In this regard, building a new app is playing tennis without a net, compared to the challenging game of enterprise development.
2.  The life cycle of startup code is measured in weeks or months, rather than years. Large parts of the application are rebuilt on a regular basis to add new features. If the company does so well that the code is running five years hence and starts getting crufty or unmaintainable, that means the early developers are doing pretty well. So the early developers don't worry so much about the long term.

In enterprise scenarios, few projects are fully "green-field." If a new project is valuable enough to execute, it's gaining some of that value from existing business data and systems. Examples include projects to provide new access to existing customer records, or a better way to process an existing transaction.

In addition, enterprise code will be around for a long time - typically 2-5 years and occasionally as long as decades. Over that time, maintainability is critical, as is resilience in the face of restructuring and staff turnover, compliance with changing regulations, and adherence to business continuity planning rules.

If you spend a good part of your career at a large company, you may be the one paying the price in the future for a poor technology design today. Think about those utility scripts you write day-to-day: the idea of building and maintaining a mission-critical business application with those kinds of scripting languages should make you nervous.

Remember how easy Visual Basic was for those first apps in the early '90s...and how difficult it became to modify and maintain those apps in production years later? And those data-access samples in the magazines look so easy...but the authors don't know that your company's "Customers" table is split across two legacy databases and a mainframe.

As an enterprise developer, you have different and longer-term concerns.

Issues Facing Enterprise Development with AJAX Technologies
A number of characteristics of AJAX technologies create tricky - or at least thought-provoking questions - when we bring them into the enterprise.

Some of the popular languages and runtime options are young and still evolving quickly. There are hundreds of AJAX toolkits in use today. Only a few of these will still be in wide use in several years. Even the most popular libraries are adding features and fixing problems at a prodigious pace. While this is a great sign of their vitality, it means there's a new version every few months.

There is also reason for concern over running interpreted scripts as production software, whether in the browser or on the server. While scripting environments are used successfully - and power some of the most successful applications on the Web today - transitioning from a traditional code-compile-link-deploy-test methodology may be challenging for your software organization.

Because there is no compile/link step, you'll only find problems when your code hits them; you'll find missing dependencies when they break the app at runtime. We'll look at approaches to mitigating these issues. It also doesn't help that software teams using scripts extensively as "duct tape and baling wire" may have developed scripting habits that are not suitable for production code.

Next, we see that the languages are fundamentally different from what enterprise developers typically use. JavaScript, for example, is at its core a functional programming language, where functions, with their closures, are the fundamental construct in the language and serve to control scope boundaries. JavaScript, and other scripting languages such as Ruby, are also dynamic. This means that significant parts of the program code may be generated at runtime based on external data or the branch path an application takes. Metaprogramming - programs writing themselves or other programs - is fairly common in these languages and, even if you don't use these techniques, you are likely to encounter libraries that do so.

As we've said, enterprise applications are also less likely to be green-field projects. What does that mean for AJAX development?

For one thing, test-driven-development techniques, a cornerstone of building solid code with dynamic platforms, become trickier. Since enterprise apps often span many systems, it is harder to assemble a full test system that can be manipulated by automated testing. The data in the test systems may not be complete, or may be encumbered by privacy issues. The test systems may be formally controlled or resource constrained so that continuous testing may not be allowed. Proper testing of gateways from partner companies may be hard or impossible. And, since real-world legacy data is not all clean and up to date, you need test data sets that cover these dirty or incomplete-record scenarios as well.

If your application needs to access existing non-HTTP-based network resources, you will need to do some special planning. Pure AJAX is restricted to HTTP; if you need another TCP protocol, or UDP, you'll have to plan on deploying to a plug-in environment in the browser or using a proxy on the server side.

The overhead of deploying additional server applications just to serve as proxies to other systems (a common AJAX technique) could be considerable in the enterprise. And, finally, your data access layer needs to be both compatible with your legacy schemas (something not handled equally well by all of the popular frameworks) and compatible with the rules and leanings of your DBAs.

Adapting to the Challenge Wrangling Platform Versions
There are two basic approaches to dealing with version changes: controlling the version in use where possible, and leveraging abstraction layers to hide version differences. I recommend using both techniques as much as possible.

On the server, you have control of all of your library versions (including JavaScript that is served to run in the client), and many of your interpreter versions (e.g., Ruby or Python on the server, but not the JavaScript or Flash runtime in the browser). Think of the interpreter as a runtime library and consider deploying it together with your server app.

On the client, a key evaluation criterion for a JavaScript library should be its cross-browser, cross-platform abstraction capabilities. Your AJAX toolkit should handle the differences between Safari and Firefox, Mac OS and Windows, leaving you to focus on core UI and business logic. Because of the rapid evolution of AJAX toolkits, you may even want to consider a minimal abstraction layer of your own to mediate between your code and the underlying toolkit, to ease potential toolkit changes.