I think the lisp situation is peculiar, for 3 main reasons:

- most of them are dynamically typed (thus don't need sum types, as there are no types). The ones that do have gradual type systems likely either implement some form of them (off the top of my head I can only remember typed racket, and I think it implements them through union types)

- not all lisps lean functional: I believe that's mostly a prerogative of scheme and clojure (and their descendants); something like CL is a lot more procedural, iirc

- in most lisps, thanks to macros, you probably don't need the language to support some sort of match construct out of the box: just implement it as a macro [1]

In general the "proper sum types" side of functional programming is just the statically typed one, but even in dynamically typed FP languages you end up adopting sum type-esque patterns, like elixir's error handling (which closely resembles the usual Either/Result type, just built out of tuples and atoms rather than a predefined type), and I assume many lisps adopt similar patterns as well

[1] https://github.com/clojure/core.match

Those are covered in Common Lisp, Scheme/Raket and Clojure, which are the Lisps most folks would be using, not Lisp 1.5 from McCarthy days.

Most Lisps have some sort of pattern matching in their standard library. Common Lisp has sum types with deftype.

(Pure) expression orientation is the true marker of FP