The problem is that with multiple devs working on the code base. If a developer pushes a folder to the repo with changes to File A, and I come behind their commit with an entire folder on File B, then my push will contain the old version of File A and overwrite the first Developers change.
This represents a problem in your software development lifecycle. You should never allow a PR that overwrites existing code to be merged. This should be a non-issue that is instantly caught in code review.
However, I also want to highlight that this may represent a misunderstanding of how (most) VCS systems work. In Git, you don't commit folders; you commit files. If User A merges changes to File A, and user B then makes changes to Files B and C in the same folder, no overwrite occurs: Git versions the files separately.
The problem is that with multiple devs working on the code base. If a developer pushes a folder to the repo with changes to File A, and I come behind their commit with an entire folder on File B, then my push will contain the old version of File A and create a merge conflict.
This is still a misunderstanding, unless possibly if you are using a source control system that is not Git or Mercurial. Folders are not versioned, files are. The scenario you describe would not result in a merge conflict, which would occur if the two developers modified the same file in ways that conflict with one another.
Merge conflicts are simply a part of life in team development. Ideally, they happen rarely because your code base is well structured and your developers work on separate stories. But they will happen, and you'll resolve them in source control before a merge takes place and before an org is ever touched by CI/CD.
Merge conflicts also have nothing to do with delta deployments. Delta deployments do not fix merge conflicts. If you fail to resolve a merge correctly, your source tree (your source of truth!) is now wrong, and out of sync with your org. That will cause problems at some point whether or not you use delta deployments.
More broadly, you can use a plugin to generate delta deployment packages. I personally think this is a bad practice. I advocate for either deploying all metadata every time, or (as sfdcfox described) using inherently-versioned packaging rather than deploying unpackaged metadata.