The author of the article cites an attack at target basically against tiny embedded computers in a cooling unit and point of sale systems, then goes onto push a virtualization security approach that apparently can solve these problems. But it's not as if these embedded computers are going to be running such hypervisors or virtualization stacks so you're really not solving the problem there.
I suspect the issue at target was also much more complex than just compromising some cooling unit and there all of a sudden you have unrestricted access to the credit card terminals. PCI (I think PCI existed back then) has pretty strict rules about limiting access to "in scope" systems. But can certainly understand getting a foothold then allows you to get access to other things and maybe you can get to a system that is authorized to talk "through the firewall".
But the solution being pitched only covers certain use cases, and is not a complete solution. It's not a bad idea to have such east-west traffic being processed more securely, though I know in many cases the costs simply isn't worth it (I know for the orgs I have worked for that certainly is the case, I have zero interest in costs/complexity of deploying VMware NSX for example). Even in my small networks there are a lot of things that are not VMs, and such are not going to be impacted much by any VM-centric solution.
My own hacky solution which I started using back in 2005 is network zones with basic ACLs on the core switches to limit traffic. Nothing super sophisticated, if anything it simply prevents accidental communication (perhaps misconfiguring a device/application) between zones. Higher level zones have unrestricted access to lower level but not vise versa. There are a few zones which have no restrictions on the switch level(instead such restrictions(if any are needed) are implemented on the devices themselves in those zones. The switches use ASICs for the ACLs, so while they are not stateful, they are line rate. In a few more sensitive cases I do isolate VLANs behind the firewall with more strict rules(taking into account expected bandwidth required to those zones, in those cases it's just a trickle). It's not built to be bulletproof, but has worked well for me. Not talking a lot of ACLs either, for my main network which has at peak around 1000 VMs+other gear just a couple dozen ACLs total(across about 25 VLANs). My original implementation in 2005 was far more locked down and sophisticated. I had spreadsheets with the networks and then a perl script would build the ACLs from the spreadsheets (CSV files). The core switches I had at the time supported up to 128,000 ACLs in hardware so I was able to go nuts. In the years since I decided to make it more simple.
Some folks like to go full on firewall between all subnets, and that can work too of course there are more likely to be bottlenecks there.
Side note, with so much encryption being used in today's apps/services, having a firewall, whether it is east/west or north/south or whatever, really loses effectiveness if it can't decrypt the packets. Lots of things use port 443 for example, lots of things connect to services hosted "in the cloud" (which have obviously huge swaths of shared IP ranges). As far as I know(haven't checked recently) pretty much all of the "SDN" like firewall products are not sophisticated like say a Palo Alto firewall (I don't use their products either, just know them mainly from reputation) in being able to intercept and classify actual traffic , rather than just being basically blind in doing layer 4 stuff. Obviously other firewall products can do the same (better or most likely worse than PAN from what I gather). Then there are other products still like Darktrace who sit on the network and you mirror your traffic to them and they look for unusual activity in real time (I've seen some demos, never have been a customer, another product am not particularly interested in), but they too are blind to encrypted stuff.
Deployed my first network intrusion detection system in 2002 (Snort based Sentarus ran PHP/MySQL too on FreeBSD with bridging interfaces), so have been doing this for a little while. Ironically that IDS was more effective at picking up stuff than many of the current ones because encryption wasn't widely used back then vs now.