When should a team avoid adopting CQRS, even though it's a well-known, respected pattern?

A team should generally skip CQRS for a small internal tool, an early-stage product's core CRUD functionality, or any system where reads and writes have genuinely similar shape and similar traffic volume. In these cases, CQRS adds real costs — more moving parts, a steeper learning curve, eventual consistency to reason about — without providing any of its actual benefits, since there's no meaningful scaling mismatch or query complexity to solve. A practical, low-risk alternative is to start with a simple, single-model service and only introduce CQRS later, for the specific parts of the system that show clear, concrete signs of needing it, such as a slow reporting query or a read path becoming a genuine scaling bottleneck.