What I took from it is that Microsoft used to make all their money from Windows and Office, but now the company is looking to transition towards being a service company rather than a product company. As a service-oriented company, restricting developers towards a single platform doesn't really help them, so ultimately it's in Microsoft's best interest to get .NET out there as much as possible so that people will want to choose their services.
I won't admit to "getting it", but what I gather is that Microsoft want .NET to be a valid choice for everyone.
I think it's apparent that Microsoft has admitted the reality that the operating system just doesn't matter any more - and you're not going to make money there.
So it's all about services, and Azure is one of the sources of those services.
At this point, they want to do this with Azure services. Which is very easy to work against with very rich tools in .Net. They're extending this development ability to other platforms, so that hopefully people will choose to use .Net even if targeting other platforms in the hope that people will choose to deploy to Azure over other cloud providers in much the same way that I chose to deploy to windows a decade ago.
This doesn't even count migrations of existing applications, which may well be better off on Azure (in windows) with new systems under Linux. The past two years, I've spent supporting Windows applications where a next generation was moving to Linux (node/iojs). Right now I'm doing this against Azure.
Being pragmatic, I'm even using Azure Storage (queues, tables and blob) for migration data, which means I don't have to setup/configure/manage a bunch of servers to do these tasks. Setting up RabbitMQ isn't hard, but there's time involved. Setting up C* isn't hard either, but if the data is transitional (using azure tables to hold data exported from the old system, and queues to trigger import into the new), it doesn't make sense to configure my own server. After using these services, I may use them more deeply, I'm already using Azure Tables for my configuration settings even, so I don't have to maintain an etcd/consul cluster.
All of this said... while I am mindful of getting locked in, and do have a strategy for breaking out, and my core application data won't be in azure services... actually using them makes me consider using them more.
From my own experience, what they are doing is a legitimate strategy and far better than how they approached it early on, and may still be. I stopped attending .Net conferences/meetings about 4-5 years ago because they were turning into Azure sales presentations more than development presentations in general. This is also the same time node.js started to become a viable contender, and I started using it for web project client files (js merge/min, less etc).