As mentioned here,
Below are the principles for continuous delivery.
Every build is a potential release
Eliminate manual bottlenecks
Automate wherever possible
Have automated tests you can trust
In traditional build process, without using continuous delivery approach, We commit the code in master branch, for multiple reasons, mainly for collaboration among developers and testers.
With respect to first principle, How can every commit be a potential release?
It's quite simple - if you created a commit and pushed changes to master and after that you run a build and your automated tests are all executed successfully, then this build can be used as a release.
So, the principle is more related to build rather than to commit, but if you've configured to start a build for every change that pushed to master (Automate wherever possible principle), then in this case it's a synonym.
Continuous delivery is an extension of continuous integration, see How does continuous integration relate to continuous delivery / deployment?. And from the CI practices:
Every commit should build on an integration machine
So yes, in CI/CD every commit is going to be built and, if all CD criteria are met (emphasis on potential!), the commit is deliverable (or deployable if D in CD stands for deployment). If not then the issue must be addressed.
There may be exceptions, for example due to business requirements or resource limitations, in which the delivery/deployment pipeline is not triggered for every successful CI commit. But that complicates identifying and fixing regressions.
But committing changes with dependencies on other, not-yet-committed changes (as mentioned in comments) is not compatible with the CI/CD methodology. Work-in-progress commits in such context are still possible using feature toggles/flags and/or branch-by-abstraction techniques which can hide temporarily unsatisfied dependencies in order to not cause regressions.