You are right, point-in-time restores are not possible with full VM restore. However, you should be able to perform file level restore of MDF file from latest backup, and then apply new transaction logs on top of that for point-in-time restore. I have not tested this myself (and I am not big SQL guy anyway), but I am sure you know best what can and cannot be done with SQL for restore.
No, we definitely do not expect customers who are intentionally using full recovery mode for point-in-time restores to prune logs after successful backup. However, while I am sure this will be totally surprising for you, there are quite a few customers (especially in small business, where there are no designated DBAs, but rather do-it-all administrators) who are using full recovery model just because it is default model for new databases starting SQL 2005. They do not need point-in-time recovery (and do not even realize this functionality exist), they are just fine restoring previous full SQL VM backup with some data loss, which is typically perfectly okay for their business. Of course, the proper solution for anyone who does not need point-in-time restores is to just switch databases to simple recovery model. But this is only obvious if you know Microsoft SQL
and many do not.
Now, because these customers are not doing anything about their transaction logs (again, in most cases do not even know these logs exist), the logs just grow forever, fill up all disk space, and start causing very real issues to production database. Then, they would typically do some Googling, or ask customers on various forums, and often people will them that logs are truncated after backup only. And so they come to us opening severity 1 support cases and blaming our product for not truncating those logs. Nothing pretty in general, and while the fix is easy (simple recovery model), downtime did happen.
So, to prevent this for happening in future, we have built the capability to truncate those logs into our product. Supposedly, this should make everyone happy now... those who really need full recovery model for point-in-time restore will not want to use log pruning, as you correctly stated. And people with little SQL knowledge will get their logs truncated, thus keeping production VM healthy.
I hope this answers your question? If you have any suggestions on how we could improve image-level backup for SQL servers on top of what we currently have, I will be interested to hear!