It may also be useful in the rare case when you have to specify the namespace (for disambiguation), your namespace isn't so long to justify the alias, but is likely to change soon (like when you're using namespaces to support two versions of your code path simultaneously):

They're useful when you have conflicts. For example, if you have types NamespaceA.Jobber and NamespaceB.Jobber, and want to use them both in the same class, you won't be able to just add using statements for NamespaceA and NamespaceB, because then the compiler won't know what you're referring to if you type Jobber. In this case you'd give an alias to one or both of the namespaces.

This can make your code clearer, especially if the namespace is long, because the alternative is to have the whole namespace written out each time you use a type.

Namespace alias are useful for resolving ambiguity of two or more class with the same name in your code. For example you have Button class from your winform and you also have a Button class from your 3rd library. When youur code refer to Button, you may want to quantify it to from the 3rd party and not wanting to put the full long text everywhere and rather use the alias using CompanyX = CompanyX.UI.Animated.Control ... CompanyX.Button

In fact I'm just using it earlier in a work project to also make my code more readable. I use Office Word automation and instead of having variable Application define everywhere and hard to differentiate it from my actual Application class, I define using Word=Microsoft.Office.Interop.Word and in the code I can say Word.Application to refer to Word application object