Neither does a filesystem snapshot unless the snapshot is aware of every application's consistency semantics. You can't simply assume that every flush() or other write barrier means that the application data is now in a consistent state on-disk.
These days, with production systems being componentized across VMs, abstractions like LVM in use, etc., the filesystem is no longer a fixed "feature of the deploy environment" chosen separately from the needs of the application, that needs to cope with any random thing the production application might do; but rather, a prod deployment is designed as a whole, where you choose the filesystem and plan the use of its features relative to what application you'll be deploying on it. (And, in fact, for a stateful application like a DBMS, you'll probably have one or more separate volumes just for the application state — so the filesystem you use to solve application-state problems doesn't even need to be good at being a rootfs for an OS; it only needs to be good for your application use-case.)
Under this paradigm, rather than trying to make a filesystem that understands applications well enough to snapshot them, you instead make applications that have filesystem snapshots as part of their conceptual model.
In the lower-effort version of this approach, you have software like Postgres, where the application layer can be told "I'm going to use filesystem tooling to take a consistent snapshot, so make your on-disk state consistent for a while." In PG, you'd call pg_start_backup(), which will flush all pending writes to the table files to disk, and then spool all future writes purely in the WAL journal until the backup completes (i.e. until you tell it pg_stop_backup()) — at which point all those pending changes get replayed out to the table files.
In the higher-effort version of this approach, you have software that has one or more CoW filesystems it natively understands and integrates with — where you never directly address the filesystem at all, but rather, you tell the application to take an application level snapshot; and then the application uses the filesystem CoW features, together with its own consistency primitives, to efficiently achieve that (which might not necessarily result in something that's a "filesystem snapshot" from the FS's perspective, but rather just a bunch of individual CoW-cloned files in a directory.) I believe that Oracle DBMS does this, though I might be wrong.
So I guess you'd have to temporarily turn on CoW, take a snapshot, make sure all the files are fully duplicated, turn off CoW to achieve that. Since you can't flip the setting at runtime right now, that feature seems quite far away.
As you say, it's a consistent copy. cp(1) won't give you that.