I think its just personal choice tbh - but I cant vouch for bv enough from my side. Some reasons for it over chk:
faster - bv creates in memory dictionaries/keyed tabs of missing partitions-tables rather than on disk files that chk does - thus much faster to run, much faster to access during select,
pointless files - the empty files created as a result of chk are pointless, imo, causing unnecessary reads and files to live in the db, (forever btw!),
cpu/disk - hundreds if not thousands of these files, depending on how many columns you have in total across your database, can cause a)open fd limits to be hit quicker, b)cpus to be used needlessly (due to compression, serialisation, reads etc of these files), disks to be used neddlessly more due to the unnecessary reads and d) backups to be slower. Of course several factors at play here, but mostly still stands.
compression - compressed empty files in cases take more space then non-compressed empty files, and certain compression scripts simply go over the database and compress every partition, or, certain partitions based on a compression strategy,
permissions - chk requires write permissions on hdbs - It cant be run if a) the hdb q process is started up using a different user id than that of the owner of the files in the hdb (as can the case at times to avoid system forks having the ability to delete data), b) if reval or read only mode is in place on the hdb (although bv would be blocked here too with 'noupdate),
redundant tables - I dont like the idea of retiring a table at some date and still creating empty files for it (daily/parition-ly) several years in the future (in my experience we have always kept the retired tables in the database, but never actually deleted the data),
reload - A reload is required after .Q.chk has been ran, bv doesnt require a reload. Reload time always matters!!
I am sure there are reasons for chk, such as keeping the structure strict within the file system etc , but its not for me.
Sean