"Smart UI" is only an antipattern in that it's basically incompatible with domain-driven design. Evans specifically calls out that if you're not adopting the pattern of having a UI layer, a (thin) application layer, a domain layer for defining business state and applying business rules, and an infrastructure layer, a "smart UI" is very likely the best choice, because it's superior to a half-assed layered approach (e.g. one that blurs the line between at least two of the application, domain, and infrastructure layers). Evans' intent would appear to be to have you ask if a "smart UI" is viable, and if it is, then you probably shouldn't even bother with doing DDD, which is generally going to be more difficult.
The situation where a smart UI is called for is if the application is dominated by data entry and display with any business logic being simple enough that it can be readily encoded in the UI. In that situation, Evans recommends putting the domain logic in the UIs (plural because each bit of functionality will tend to go in its own UI) and have that UI more or less directly interact with a relational DB. The old-school server-side-rendered PHP approach or your typical VB app of 20 years ago are basically paradigmatic.
Evans cites advantages including a very fast initial delivery of a simple application by developers who are comparatively unskilled at modeling a domain, ability to rapidly adjust to requirements changes (as long as the complexity of the requirements doesn't increase), and visual (low-/no-code in modern parlance) tools are likely to be quite usable for this. Disadvantages include limited ability to integrate with other applications/services (since the integration is through a relational DB, this tends to mean that an integration requires modification to anything it touches), reuse of business rules largely occurs through copy & paste, the lack of abstraction makes refactoring difficult, and there's a fairly low ceiling for how complex the functional/non-functional requirements can get before the ability to deliver those requirements disappears.
Agile was largely coming on the scene at the same time Evans was developing DDD, and it's pretty easy to see how an agile approach likely favors smart UI. Note however, that adopting smart UI is only prudent if you can be reasonably sure that you know how the requirements will evolve: if you view design decisions as being partially about accumulating, to use a financial metaphor, call options on future requirements, you're writing call options to harvest the premium by doing this. If you're doing this after carefully mapping out the problem and deciding that the requirements aren't going to move in that direction, then it's probably analogous to covered-call writing, but assuming YAGNI in a smart UI is closer to "shorting volatility" (often described as picking up small-value coins on the street in front of a steamroller: you make small profits until you get wiped out).
It's also worth noting that Evans' main argument for smart UI being faster to deliver largely hinges on the need to implement (and manage) an infrastructure layer. Since Evans' book, one could argue that the difficulty of implementing those has largely been eliminated by the rise of frameworks supporting DDD application development (e.g. Axon, Akka, Vlingo, etc. (to only name JVM-targeting frameworks)) as well as widespread messaging systems (Kafka, Kinesis, *MQ, Pulsar, etc.), object storage, etc., with the overall effect that the complexity level at which the DDD approach is worth the extra effort has come down.
