Short answer
The goal is to keep core domain logic free of framework annotations so it's plain Java that's fast to unit-test without a Spring context and portable if the framework changes; you push @Service, @Repository, and @Transactional into the application/infrastructure layers.
Explanation
The trade-off is some boilerplate and explicit wiring instead of letting annotations do everything, and pragmatically many teams allow a little framework leakage to avoid over-engineering a small codebase. The defensible senior position is to protect the genuinely valuable domain rules from framework coupling while not turning purity into dogma for trivial CRUD, and to enforce whatever line you choose with an ArchUnit test.
Common mistakes
- Putting JPA and Spring annotations everywhere in the domain.
- Being dogmatic: sometimes a pragmatic dependency is fine.