Drive Configuration In Virtual Environment My company is getting some new VM (VMWare) servers provisioned for purposes of installing SQL 2014 or 2016 (version to be determined) with AlwaysOn Availability Groups.  The server and storage provisioning is being done by managed services within the data center.  

As a DBA with the company, I recommended our standard drive layout (OS, App, SqlData, SqlLog, TempDB, and SQLBackup), so six drives per server.

The Virtualization Lead with the data center is recommending just two drives per server.  One for OS/Apps, and the other for SQL.  His exact response was "With an aag [AlwaysOn Availability Groups] and modern storage, we can typically flatten it out to an OS and a SQL disk.  The era of separating disk groups to alter performance  is behind us with object based arrays on the back end".

To me, this configuration seems counter-intuitive to everything I've been taught and experienced.  

My question is this:  Are modern storage arrays (I have no insight into what the actual infrastructure is, other than it's supposed to be "state of the art") getting that good that we don't need to manage for splitting up IO for data, logs, and TempDB?

I won't be managing the servers, nor even doing the SQL configuration on them, so I don't have much skin in the game.  I'm more interested in hearing if this is others experience on server drive configurations going forward as we move to better virtualized environments.  I should note that the data going on these servers will not likely have a high amount of IO, so I don't think performance will be a real factor.  The two main priorities are that the system has very high up-time and is very secure.
I think it comes down to the IO subsystem your vendor is using. If it is still spinning disks, then for performance purposes, what you suggested is best practice. However nowadays, with all-flash storage arrays (SSDs), there are no moving parts, thus the IO patterns are not much of a concern anymore. 

Bottom line, your vendor should be well-versed with what best practice is for SQL Server install. I suggest asking for supporting documentation to be safe. For example, VMWare has a SQL Server on VMWare Best Practices Guide.pdf which pretty much spells out the above.