If everything is together, then updates are easy no matter what kind they are - changes get merged, deploy runs. This makes it a lot easier to do things like roll out infrastructure changes across a large fleet, because you can just make the change and it gets picked up in each service the next time they deploy. For this to work though, you need to have good enough automatic monitoring that if it breaks something, the people deploying it will know and be able to roll back, whether or not they have the full context (usually they are either ops folks who don't have the app's context, or devs who don't have the context of the infra change).

Separating the two is safer if you don't have those guard rails yet, because it ensures that when a junior developer is deploying a small change to their app, there's no chance it's going to also like, delete the cluster. People who own the infra do infra deployments, people who own the app do app deployments.

That does require some coordination, and especially it can be hard when you have dependencies between them.