I see your point now, when IO is completely quiesced and RAM also saved to disk, there should be no difference how it was quiesced and flushed. I'm not 100% sure about that - it may be true, but I also notice that when you look at other app-consistent backups, there are pre-freeze scripts and as the name says, they are supposed to complete before quiesce commences. So I'm not entirely sure if OS-level quiesce w/o RAM being saved as well (vSphere Client 6 ignores Quiescing if Memory snapshot and Quiescing are selected at the same time, not sure about later versions) would result in identical consistency as with a SQL-aware snap (with pre-freeze, etc.).
I think it's mainly that SQL-aware operations are available, as highlighted by OntapForum, e.g.:
SQL-specific:
vs. generic Windows:
SQL-specific features may save time on running SQL-specific commands to verify, or clone/restore. It may also (not sure, see [1]) help you get app-consistent snaps on Win OS with SQL data on dynamic volumes.
Some time ago (2-3 years ago) I tested VM-level quiesce + snapshot under load 10 -20 times in a row, and never experienced a problem with SQL Server coming back. But I recall some transactions would roll back, indicating that they were available in memory, but didn't make it to on-disk transaction log.
You could check in your environment: make a clone for testing, get top INSERTs and run them in a loop while taking one of each (VM-level vs. VM with SQL plugin), and then clone those and observe SQL Server log on each clone's restore and SQL startup.