Is there ever justification for the "pseudo-typedef antipattern"?

For public interfaces I don't like to see generic types, because they have no meaning. To me seeing a method with an argument of HashMap<Long,Map<Integer,String>> is much like those C methods like foo(int, int, int, void*, int) and so on. Having a real type just makes code a lot easier to read. For a public interface it would be better to create FooBarMap that wraps HashMap<Long,Map<Integer,String>> rather than 'typedef,' but for class-internal use I see no down-side at all.

The real problem is that this idiom creates an high coupling between your pseudo typedef and your client code. However since you are using FooBarMap privately there are no real problems of coupling (they are implementation details).

NB

A modern Java IDE should definitively helps to dealing with complicated generic types.

IMO, the problem with Java anti-patterns is that they encourage black-and-white thinking.

In reality, most anti-patterns are nuanced. For example, the linked article explains how pseudo-typedefs leads to APIs whose type signatures are too restrictive, too tied to particular implementation decisions, viral, and so on. But this is all in the context of public APIs. If you keep pseudo-typedefs out of public APIs (i.e. restrict them to a class, or maybe a module), they probably do no real harm and they may make your code more readable.

My point is that you need to understand the anti-patterns and make your own reasoned judgement about when and where to avoid them. Simply taking the position that "I will never do X because it is an anti-pattern" means that sometimes you will rule out pragmatically acceptable, or even good solutions.