Yes, People still "think" this. And it's in your best interest to read the platform documentation for the systems and applications you're leveraging before you make decisions on whether to go physical or virtual.
As an example of the "scalability problem", Microsoft has documented their Exchange 2013 Preferred Architecture--which is pretty much 2U, 2CPU servers with JBOD of 7200 RPM disks. Essentially, you take away what you think and know being a VM platform guy (Snapshots, SANs, LUNs, RAID, etc.) and throw it out the window because none of it applies to Exchange 2013 (and newer). Microsoft, and other application vendors, have built resiliency into the application stack. Because of this, all of your traditional VM methods of failover (host failover, DRS, HA) do not apply to the technology. Or rather, is an unsupported configuration which may result in performance problems at best, and data resiliency problems at worst.
The links below don't necessarily say don't virtualize, but they do say to understand the design they're going for and build appropriately (scale out, not up). VM Architecture is a massive overhead cost in comparison of throwing a bunch of dumb servers together and saying "make it work".
http://blogs.technet.com/b/exchange/archive/2014/04/21/the-preferred-architecture.aspx
http://blogs.technet.com/b/exchange/archive/2015/06/19/ask-the-perf-guy-how-big-is-too-big.aspx
This is just one particular item that I think doesn't lend itself well to virtualization, but another area is SQL server--where the disk i/o requirements of SQL are so intense that it's cheaper to build out a dedicated SQL cluster than it is to build out a virtualization environment that meets the disk i/o needs of the databases.
An application which leans heavily on iops workload is something like Sharepoint (https://technet.microsoft.com/en-us/library/cc298801.aspx). Microsoft strongly recommends dedicating a cluster to Sharepoint, do not share (do not add an instance to a cluster running other applications), and that for a large size you may need some serious iops.
Again, these things aren't impossible to virtualize. But the raw needs of both of these applications lend themselves better to physical hardware rather than being tossed on a VM cluster. By the time you dedicate enough resources (whether CPU time, dynamic memory usage, or io priority) to these apps, you would have been better off just buying some dedicated physical hardware, and you'd end up with much better performance.
Yes, for a lot of workloads VM is great. Things like low end application servers, scale-out web servers (using web clusters preferably where you can) are great. You can get a lot of VM density on a great many workloads. But not everything can be done this way. Unless you want to put 100Gbps links in all of your physical servers going to your storage clusters...and SSDs everywhere.