No, it's not an anti-pattern. I can think of a number of practical use cases for this:

1. If you want to use compile time checking to make sure collections of objects only conform to one particular subclass. For example, if you have `MySQLDao` and `SqliteDao` in your system, but for some reason you want to make sure a collection only contains data from one source, if you use subclasses as you describe you can have the compiler verify this particular correctness. On the other hand, if you store the data source as a field, this would become a run-time check.
2. My current application has a one to one relationship between `AlgorithmConfiguration` + `ProductClass` and `AlgorithmInstance`. In other words, if you configure `FooAlgorithm` for `ProductClass` in the properties file, you can only get one `FooAlgorithm` for that product class. The only way to get two `FooAlgorithm`s for a given `ProductClass` is to create a subclass `FooBarAlgorithm`. This is okay, because it makes the properties file easy to use (there is no need for syntax for many different configurations in one section in the properties file), and it's very rare there will be more than one instance for a given product class.
3. [@Telastyn's answer](https://softwareengineering.stackexchange.com/questions/274587/constructor-only-subclasses-is-this-an-anti-pattern#274588) gives another good example.

Bottom line: There isn't really any harm in doing this. An [Anti-pattern is defined to be:](http://en.wikipedia.org/wiki/Anti-pattern)

> An anti-pattern (or antipattern) is a common response to a recurring problem that is usually ineffective and **risks being highly counterproductive.**

There is no risk of being highly counterproductive here, so it's not an anti-pattern.