Log and Data Drive Configuration in VM environment
It really depends on what's best for your situation as long as you follow some guidelines.  We keep the disks for transaction logs separate because often RAID 6 doesn't give us the IOPS we want during peak usage, but many times it does.  It depends on your peak IOPS requirements, future growth, and file management. Note that these best practices were created when 7200 and 10k RPM magnetic disks were still expensive.

Isolation, Throughput, Management, and Tail Of Log Backups

One issue with putting it all on 1 big array is that different workloads will now affect your log files where before it wouldn't.  If someone does a SELECT * on a huge table and it has to load it into memory, you're fighting for resources off the disk now. All of a sudden you have a different workload when you're trying to troubleshoot what happened.  

However, Perhaps you have really good SSDs and your peak writes won't really matter.  Another item is you could configure write cache on different arrays so you could dedicate your entire cache to log files.  Again, if you're on SSDs on your workload, or you don't have those caching options that might not matter.  Another reason to have your own array was to short stroke the disks, that was very helpful for magnetic disks.  Remember that data fragmentation could affect the log file too.  Sure you could have VLFs (logical fragmentation) taken care of easily but what happens when the underlying disk decides to move data around or you get fragmentation due to how the files are growing?  In many cases that won't cause a problem, and in some it will.  

Also, note that if anything happens to that array, physical OR logical, you can kiss tail of the log backups goodbye.  If your data loss requirements are OK with that then make sure to get that in writing.