Well, kind of, yes. It's security by obscurity because you still have a public endpoint with a public IP address, it's just that it's attached to a load-balancer. Having NAT rules for the RDP endpoints on each VM would allow you to map high ports on to 3389 (rdp). So an attacker would have to know which port to use to get to a login prompt on the VM. They'd obviously know the URL because it's the URL of your website. They could just do a port scan at that DNS name.
Having additional IP addresses for each VM increases the attack surface by adding extra IP addresses, which I think is your point. But your attacker would have a more difficult time finding those IP addresses than scanning the ports at a known DNS name.
But then again, there are limitations on the numbers of IP addresses you can expose. Also you could put NSGs to allow only certain external IP addresses through. But you can also do that, for the RDP protocol, on the load balanced endpoint as well.
At the end of the day you have to make some decision on how you protect it, one way or the other - with each having their own advantages and disadvantages.
Perhaps the best way to achieve this is to have no directly attached IP address (ie have all traffic coming from the load balancer) but have NSGs to forbid all traffice except HTTP (and possibly SSL). If you want to RDP in to the machines, you have a site-to-site VPN from your on-prem infrastructure. That way you'd use an "internal" IP address to get to RDP for those times you need to configure something or perform troubleshooting.
But thanks Viron - it's a good point you make. I made the video to show how to configure these things, rather than give security guidance on which method to choose. Until recently, the Public IP address, Load Balancer, NSG etc didn't appear in the Azure portal and you were forced to use Powershell/CLI/REST/Resorce Group Templates. It's probably easier to test and experiment while things are in the portal's UI.
Thanks for your observations.