The key is who is running that "specified collection of servers". If they're all yours, then yeah, there's no advantage to just running your own sql-ish cluster.
However, what if now your p2p miner pool includes a few machines run by your regulator? Yes, your business logic endpoint nodes are participating in a one-way fashion, but their transactions are now being automatically logged by the regulator (regulator doesn't need to know what the underlying business logic is, just that the reportable transaction results are being logged in the blockchain they're part of). Something like a third of financial firms' business is around reporting requirements.
Or consider a large supply chain... again the miners aren't just one company, it's everyone in the supply web or the consortium. Allows for coordination without necessarily being open to the public.
What this framework appears to do is enable your endpoints to participate in a one-way fashion. So they will get just enough information to facilitate a transaction but nothing beyond that.
It seems like a bit of cloak & dagger tomfoolery where the blockchain is just being implemented behind-the-scenes on a specified collection of servers but I haven't looked very deep yet. I can see the benefit to Microsoft from having a setup like that--they can allow customers to participate in a blockchain-utilizing system without giving them full access to the blockchain but to me that seems like defeating the purpose and unnecessarily trusting a 3rd party to handle all your transactions with no independent way of verifying said transactions.
In other words, it's no different than just standard server-client architecture except instead of handling transactions through a database (the traditional way) they utilize a blockchain in the background. When you want to verify a transaction you're really just making a request to their central server and asking it to do the job for you--and trusting whatever it tells you.
Not exactly a proper blockchain if you ask me.