Yeah, Python's random module uses MT, but you can use PyCrypto, which provides an API-compatible cryptographically secure module (PyCrypto.Random.random).
In Perl for example:
http://search.cpan.org/~mkanat/Math-Random-Secure-0.06/lib/M...
For instance, you definitely need it in poker hand generation - would you need it for random loot generation in an MMO?
Also by "secure" you mean /dev/random, and /dev/urandom is used as if it was rand()?
Even in randomized algorithms you may have to be careful what RNG you use, because of DDOS risk. For example see the problems with Python and Ruby hash tables that could be exploited to have worst-case behavior because their behavior was entirely predictable.
In a MMO you most certainly want to use a secure RNG, as cheating is rife in them. If a player can get an advantage by predicting the RNG, someone will.
/dev/urandom is fine; in Ruby apps, I'd use OpenSSL::Random.random_bytes or ActiveSupport::SecureRandom.random_number.
Do those functions just read from /dev/urandom?
I want to respond to this headline, though. Use of MT as a CSPRNG is very, very common in PHP applications. And it's also true that MT is the algorithm used by Ruby for it's "rand". But this is not a very common Ruby flaw, at least not like it is in PHP, because virtually every Ruby build provides an explicit secure random number generator, either through OpenSSL or (more commonly) through Rails' SecureRandom.
You should know that unless your RNG calls itself "secure" or "cryptographic" --- like, in the function name --- you are using rand(), not a CSPRNG, and you can't count on it for security ever. You will have the exact same problem in most mainstream languages. Secure random number generators say they're secure. Nobody says Ruby's rand() is secure.
(I'm pretty sure the same is true of Python, but I'm less confident of the specifics. I think this is a very fair issue to raise with PHP in general, though.)