Ótima dúvida! O modelo que você sugeriu é totalmente válido e funciona muito bem quando o foco é feature co-location. No meu caso, a escolha foi mais alinhada com DDD e separação de camadas: eu trato features/ como a camada de aplicação/domínio (use-cases, regras, fluxos) e components/ como camada de apresentação, que muda mais rápido e não deveria “contaminar” o domínio.

Em DDD, autenticação e usuários costumam ser capacidades transversais, usadas por vários contextos e interfaces. Separar UI da lógica facilita reaproveitar o domínio em outros cenários (admin, API, novos fluxos) sem arrastar decisões de UI junto, além de evitar que um “users” ou “auth” vire um mega-domínio acoplado à tela.