It may be a good fit for Dropbox, but that doesn't mean it's going to be a good fit for your company. You're probably best off using what's suitable to the task and that you have a team that's familiar with. If your programmers are all, 'let's use C' and they've got a good argument for that suiting a particular problem domain, (and you're not somehow tied down to using another language by need to work with what another company is doing...) then it may be a good idea to use C. Same with Lisp or Python or....
There are going to be trade-offs there; (what library support is available, what sort of community of programmers you're buying into when you choose that language, how the semantics let you fit it into a particular production/design paradigm, are the really major ones to me.) So, it's not quite free choice. But those are discussions that ought to happen if you're going to sit down and choose a language.
I've always been quite impressed with how fast, low footprint, and solid Dropbox is given that it's in Python.
The problem with VM languages (Java, Python, Ruby, all of them) is that the VM itself and its libraries constitute an enormous dependency that you must either manage compatibility with if you are to use the natively installed one or ship with your product. The latter offends my personal aversion to bloat... I hate shipping something where there's 100X as much data in dependencies than in the product itself. "Here's my 2MB app and its 120MB of VM bloat..."
Python has some decent tooling in this area, so that helps. But VM language authors take note-- this is a big problem that needs to be solved.
Also why I find Google Go interesting: it's compiled as far as I know, and requires few dependencies to ship. (A few libs? That can probably be static if you want?)
I think the broader point is to use a single language over as many of your system's as possible. Rather than just "Python is the answer to everything."
Obviously there are benefits and drawbacks to such an idea. Benefit is every programmer you hire can be a Python developer. Should make meetings fairly simple. You need to worry less about ensuring you have an adequate number of x developers to maintain the system which relies on language x.
Obviously the drawback is that Python, like any other language, isn't the best choice for everything. To get round such inefficiencies Dropbox choose to buy larger machines.
It may be a good fit for Dropbox, but that doesn't mean it's going to be a good fit for your company. You're probably best off using what's suitable to the task and that you have a team that's familiar with. If your programmers are all, 'let's use C' and they've got a good argument for that suiting a particular problem domain, (and you're not somehow tied down to using another language by need to work with what another company is doing...) then it may be a good idea to use C. Same with Lisp or Python or....
There are going to be trade-offs there; (what library support is available, what sort of community of programmers you're buying into when you choose that language, how the semantics let you fit it into a particular production/design paradigm, are the really major ones to me.) So, it's not quite free choice. But those are discussions that ought to happen if you're going to sit down and choose a language.