If your use cases are commands, which are sent to some mediator to be processed by an handler, you can easily implement a validation pipeline that ensures your commands are valid. If you implement a simple global exception handler middleware that converts the validation exception to a HTTP 400/422 you won't need to replicate business validations to your API models.

Even if you don't use a mediator, but your use cases implement some generic interface, you could easily use the decorator pattern to achieve the same validation pipeline approach.

Nonetheless, despite the validation duplication, your approach ensures Open API definitions include validation specifications which may be important for some solutions and your article is relevant for those.

Overall it is a good article, I would just change the deserializer to not assume default values when parsing fails. Imagine a use case that an empty EAN is a valid input, your deserializer could be hiding invalid data sent by some client.