I think that Mathematica is a great prototyping environment, and has a bright future as a system for both prototyping and implementation of complete components of other systems, from back-ends to front-ends. In my opinion, we are now witnessing the process of it being transferred from pure scientific tool to a general software engineering tool / language.
So, I think that moving to another language can be often done pretty late in the development cycle (disclaimer: I have not personally built large systems involving Mathematica as a part - although I worked on large systems written in Java before - so what I write here is mostly an educated guess based on my separate experiences in Mathematica and other languages). The great benefit of Mathematica is that it is a very high-level development environment which can serve as a gluing medium for development of hybrid systems, where different parts are written in different languages. For example, I found it a great testing / development medium for Java applications. This is generally not yet quite apparent since we still lack some tools to boost productivity and overcome cross-lnaguage barriers. But I am more than positive that such tools are going to emerge pretty soon. When you develop the system, what matters is how flexible is your architecture, how testable are your modules, and how fast are the development iterations. A high-level environment like Mathematica is a great win for all these.
That said, I would not currently use Mathematica as a central run-time of the application, simply because the kernel crashes every now and then. I would make that another runtime (e.g. Java), which calls Mathematica and handles possible errors, exceptions, crashes and the like (actually, WebMathematica is just that - Mathematica managed by the Java runtime and bundled as a web application for some Java container like Apache Tomcat). Mathematica can however serve as both an excellent back-end and an excellent prototyping environment, so once again, my feeling is that one can benefit a lot from developing even large industrial systems in or with Mathematica. There are actually companies which do just that, and are quite successful.
As to when to use C etc - my advice is: as late as you can. Many problems for which Mathematica is perceived as slow can be solved quite efficiently with the knowledge of how to write efficient Mathematica code. May be even more importantly, it is rare that you know the exact method you will use for a given problem, all in advance. Once you switch to C, you will have to deal with lots of low - level details, which will increase development time and chances for errors, plus they will distract you from the essence of the problem you are solving. Even if you switch to C at the end, Mathematica can save you a lot of time in prototyping your solution, and minimize the amount of low-level work you have to do.
Scaling to large code bases:
This is a problem in pretty much every language. There are probably many factors which determine how well a given language scales. Part of this is also probably not just about language itself, but about existing development tools. For example, Java scales reasonably well, but no one in their right mind would use it for large projects without smart IDE-s. So, I'd set out a few important factors (a list is incomplete, of course):
- Type system. Strongly typed languages can use the compiler to help find errors, and this will be particularly powerful for those with type inference (ML family languages for example).
- Means for composition. These include classes / interfaces / inheritance for OO, and higher-order functions / closures / possibly macros for FP. I am biased towards FP here.
- Means for information hiding, and separation between interface and implementation. This is extremely important, and this is where OO shines, IMO. You can get it in FP, but have to be more disciplined.
- Package / module system, and namespaces - this is a very important tool for large-scale encapsulation / information-hiding
- Development tools (IDE-s, debuggers, profilers) - can make a huge difference.
- Standards of coding and code exchange. When they exist, it makes for much easier code reuse, assuming that you don't write everything yourself.
There are probably other important factors I missed. The question is how does Mathematica fare regarding these factors. I'd say that potentially, Mathematica can fare quite well. I think right now it suffers the most from a lack of certain development tools (a really good / useful debugger, for one) and coding / code exchange standards. Also, the programming practices which allow to scale to larger systems, while certainly possible in Mathematica, are not developed / not in widespread use yet. For example, closures and higher-order functions are very useful for that, but it's not something every second Mathematica programmer is using. Also, while Mathematica allows to write macros (functions which manipulate code), its rather complex evaluation control mechanisms make them hard to write. And macros are the extremley powerful scaling tool - in LISP they allow for easy creation of DSL-s because essentially they extend the compiler in the direction you want. Another problematic thing is that Mathematica is often too general, and this generality gets in the way in forms of evaluation and performance surprises. Some intermediate language layer would be a big help here.
To summarize, my opinion is this; Mathematica can be used for large projects, even at present (it actually is used for at least two huge ones: it is written largely in itself, and WolframAlpha is another example. From my personal experience, a few of my projects were several thousand lines long), but your code won't scale automatically for you, and you need to be a pretty good Mathematica programmer to be able to manage the complexity of large projects. In this regard, many modern languages provide more automatic tools for scaling the code base, and more tecniques are well-known and in widespread use. I also think, that the situation with Mathematica will improve in the future, we will have better development tools, more programming practices will be shared, etc. So, yes, you definitely can use it for large projects, but right now it won't be as easy as say in Java, Python, or some other well-known languages. Much of it is not at all inherent in Mathematica per se, but reflects its young age as a general-purpose programming language used for larger projects outside academia. My two cents.