I think the major problem here is Shvets's anti-pattern description is flawed, that is why you have problems to distinguish it from the Command pattern:
The name is flawed because it uses an older, existing term "Functional Decomposition" together with the attribute "anti-pattern".
This term was AFAIK not associated with the notion of a "pattern" or "anti-pattern" before, but by picking it for his topic Shvets gave it a new, confusing meaning. The original meaning in programming is "taking a complex process and breaking it down into simpler parts", and that is how I would use the term still today. (Note the Wikipedia definition is about the term more generally in mathematics, but I think this is probably not really helpful in our programming context.) See also this former SE post, where other people already had problems with the anti-pattern name, the top answer suggests the name "procedural decomposition" instead, but that name might lead to similar problems.
The first three symptoms you cited from the pattern description are indeed a good fit for command objects, and sometimes also for other, well desgined classes. That is exactly the reason why they are IMHO not a good indicator for this kind of "degenerated architecture" Shvets describes. See, for example, this former SE post about "classes with a single action as function"
What Shvets probably had in mind was a situation where people try to shoehorn procedural code into classes. This happens most often on a completely different scale (he mentioned "Application Scale") than the scale of a typical command object, which will often be just a small class. It results in code which is not SOLID, containing too large classes, missing proper abstractions, and classes where in most cases everything could be static, since the instantiated "object" is not an abstraction for anything else but a "module" or "sub-program", existing once and with the same lifetime as the whole application process.
Command objects, however, are more an object-oriented workaround for situations where the programming language does not provide an inbuilt mechanism for higher order functions or closures. Rember the term "Command Pattern" has its roots in the GOF's "Design Patterns" book from 1995, a time when C++ and Java were dominant, and both of these languages did not provide such mechanisms at that time. So whenever you need to pass a function around in your program as an abstraction of its own, best choice was probably to use the Command Pattern.
Today, both of these languages (as well as other modern languages) provide additional mechanisms for encapsulating functions in a data type, so often you do not even need to use the Command Pattern (in its original OO form) any more. It still can be useful if your "commands" need a more complex interface than just for the "action" or "function" which they encapsulate.