It’s kind of the same question as to why COSE_Encrypt is distinct from COSE_Sign or why there is HPKE mode_base that is separate from HPKE mode_auth and perhaps why integrated signing and encryption https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme like ECIES https://www.secg.org/sec1-v2.pdf and HPKE mode_auth aren’t more popular (seems like they have some very good characteristics to me).
Probably the main answer is that the payload is authenticity-protected in some other way — TLS, IPSec or something proprietary. End-end system architectures vary quite a lot and often have legacy components.
A good example of no authenticity at all is for-pay content distribution like streaming TV shows, sports events and such. Another may be use of an unreliable transport (e.g., UDP) and being OK with drop outs (e.g., voice or video). It’s not possible to authenticate the stream because of the drop outs and it’s too expensive to authenticate individual packets. Another might be difficulty with end-end key management for authenticity.
There are probably other examples, but I admit they are difficult to come up with. Authenticity should be strongly recommended.
In https://mailarchive.ietf.org/arch/msg/cose/fkF83PJ7f5hhe5ctERQ_7-K0FT8/ Laurence provided motivation for this feature: