"Rightsize Your Services" was Thorntail's slogan, which implied stock Jakarta EE services were oversized. Thorntail's idea was to package your application with "Just Enough Runtime" and save some bits of RAM and disk space. You were in complete control of the packaged libraries with WildFly Swarm / Thorntail, but you had also pick and maintain them.
Unfortunately: Thorntail was not as convenient as WildFly to start with and not as highly optimized as Quarkus. The "rightsizing" of the services was not worth the effort for the everyday use cases.
Wildfly Swarm and Thorntail came with MicroProfile API support out-of-the-box, which was suspiciously lacking in WildFly. In fact, WildFly was the only Jakarta EE application server shipping with only a small set of MicroProfile APIs. Now, the recent WildFly versions 19 and 20 are also shipping with full MicroProfile support as well.
Interestingly, the Thorntail's / WildFly Swarm's invention of hollow JARs, which separates the implementation and application logic in two deployment units, is supported by all application servers out-of-the-box.
Quarkus, unlike Thorntail, is not just an attempt to ship "Just Enough App-Server" by repackaging WildFly. Quarkus takes a mix of familiar Jakarta EE and MicroProfile APIs and completely revolutionizes the deployment and runtime behavior.
Now there is one recurring airhacks.tv question less to answer: "What are the use cases for ThornTail?"