Transaction Script is definitely not an anti-pattern.
From what I find about Transaction script, it is not object-oriented at all.
You are right, it is not, indeed. That fact however doesn’t make it an anti-pattern. Although it is a procedural approach, indeed, it still has its right place in the series of business logic architecture patterns – you just have to know in which case it is a best practice to use it – and in which case it isn’t. Simply put: if your problem domain is very simple then it isn’t worth the overhead to use a more complex pattern in your business logic.
Or – as Fowler writes:
When to Use It
The glory of Transaction Script is its simplicity. Organizing logic this way is natural for applications with only a small amount of logic, and it involves very little overhead either in performance or in understanding.
The anti-pattern you might think about is called Anemic Domain Model. This is the case when you intend and think you are building a Domain Model – because your problem domain is complex enough for that, – but you actually end up in a Transaction Script – because of bad code organizing / weak OO skills.