Personally, I prefer that it's all in one place. It's hard enough to get teams to update any sort of asset inventory in one place. Getting them to update it in two, and keep everything in sync, sounds like a disaster begging to happen. And, as a heavy consumer of my organization's CMDB (I work in cybersecurity), I much prefer having only one place to look.

The most successful CMDB I've ever seen was a single, unified asset tracking system which included all relevant asset details, asset owner, technical PoC and compliance documentation. The reason it was so successful was that NAC was tied to the CMDB. If a system wasn't in the CMDB, it got dumped in a very locked down VLAN which was really only useful for new system setup. Once a system was configured, the appropriate paperwork submitted, and the system added to the CMDB, it would then be automagically moved to the appropriate VLAN for it's location/function. When a system owner or technical PoC left the organization, one of the required workflows was reassigning all assets in the CMDB. This all worked surprisingly, especially considering that the CMDB was a bespoke Classic ASP website written in VB6, with some newer pages being VB.Net in C#.

Typically I've found it better to be combined both for process integration and ease of administration like you said.

It can make sense to separate it but it totally depends on the company.

I also think it's always easier to start with everything in the cmdb and separate things later if it makes sense to do so vs the other way around.

I agree with the other comments that having it all in one place is better. I think it then largely depends on how good your CMDB tool is and if it’s powerful enough to manage all those information nuances.