Why use class aliases?

Think of this the other way. There is a library and it contains a class called MySq, as the library moves on in development they think 'oh maybe we should just make one database class' so the rewrite the class and call it 'DatabaseConnection' it has the same functions as the MySql class but it can also handle Sql and MsSql. As time goes on and they release the new version 'PHPLib2'. The developer has now two options: 1, tell the users to change from MySql to DatabaseConnection or 2, the developer uses

class_alias("DatabaseConnection","MySql"); 

and just mark the class MySql as deprecated.

tltr;

To keep version compatibility!

It can be used for:

1. Changing strange class names of ext. scripts/sources (without the need to rewrite the code)
2. Making class names shorter (the class alias can be used application wide)
3. Moving classes to another namespace (@tlenss)

Surprisingly, nobody has mentioned the obvious reason why one would do this: the use keyword can only be used in the outmost scope, and is processed at compile-time, so you can't use Some\Class based on some condition, nor can it be block-scoped:

namespace Foo;
if (!extension_loaded('gd'))
{
    use Images\MagicImage as Image;
}
else
{
    use Images\GdImage as Image;
}
class ImageRenderer
{
    public function __construct(Image $img)
    {}
}

This won't work: though the use statements are in the outmost scope, these imports are, as I said before, performed at compile-time, not run-time. As an upshot, this code behaves as though it was written like so:

namespace Foo;
use Images\GdImage as Image;
use Images\MagicImage as Image;

Which will produce an error (2 class with the same alias...)
class_alias however, being a function that is called at run-time, so it can be block scoped, and can be used for conditional imports:

namespace Foo;
if (!extension_loaded('gd'))
{
    class_alias('Images\\MagicImage', 'Image');
}
else
{
    class_alias('Images\\GdImage','Image');
}
class ImageRenderer
{
    public function __construct(Image $img)
    {}
}

Other than that, I suspect the main benefit of class_alias is that all code written, prior to PHP 5.3 (which introduced namespaces) allowed you to avoid having to write things like:

$foo = new My_Lib_With_Pseudo_Name_Spaces_Class();

Instead of having to refactor that entire code-base and create namespaces, It's just a lot easier to add a couple of:

class_alias('My_Lib_With_Pseudo_Name_Spaces_Class', 'MyClass');

To the top of the script, along with some //TODO: switch to Namespaces comments.

Another use case might be while actually transferring these classes to their namespaced counterparts: just change the class_alias calls once a class has been refactored, the other classes can remain intact.
When refactoring your code, chances are you're going to want to rethink a couple of things, so a use-case like aichingm suggested might not be too far fetched.

Last thing I can think of, but I haven't seen this yet, is when you want to test some code with a mock object, you might use class_alias to make everything run smoothly. However, if you have to do this, you might aswell consider the test a failure, because this is indicative of badly written code, IMO.

Incidently, just today I came across another use-case for class_alias. I was working on a way to implement a lib, distilled from a CLI tool for use in a MVC based web-app. Some of the classes depended on an instance of the invoked command to be passed, from which they got some other bits and bolts.
Instead of going through the trouble of refactoring, I decided to replace the:

use Application\Commands\SomeCommand as Invoker;

Statements with:

if (\PHP_SAPI === 'cli')
{
    class_alias('\\Application\\Commands\\SomeCommand', 'Invoker');
}
else
{
    class_alias('\\Web\\Models\\Services\\SomeService', 'Invoker');
}

and, after a quick :%s/SomeCommand/Invoker/g in vim, I was good to go (more or less)