>Sometimes it looks like people throw blockchain in a project not on technical merits but because they think the buzzword is a VC magnet.

That's because they do. A Blockchain without decentralization (and therefore no need for proof-of-work consensus) is functionally just an immutable, append-only object database - the same sort of data structure that any modern, distributed source code version control system (like Git) has always used, before "Blockchain" was even a thing.

It's sad how often this happens. I regularly talk with people in "blockchain startups" only find out that they're the sole operators of the network. Congrats guys, you just raised $30 mil to build a highly-clustered event sourcing database

Which is true, but what’s wrong with that? Perhaps there is a valuable approach to developing apps using a “blockchain” type approach, which enables trusted or non-trusted 3rd parties to more easily drop in on it than through a traditonal API.

Well it has a few advantages like allowing trusted partners easier secure access, Maersk might not be the only party with deciding nodes, they just won’t trust you or me to run one. It also offers an easy way of offering global access through public nodes.

While your VC answer is probably the case more often than not, here is one technical answer to your question:

Instead of "proof of stake" as the consensus model, you could build a "consortium blockchain" where other parties (ie your big customers) get to validate the blocks themselves in addition to your servers. "Proof of authority" or "delegated proof of stake" are consensus models for this approach. This would be helpful if you want the data to be private but you want to increase trust within your platform.

My only guess is that they save on human auditing of some kind that is a legal requirement of the industry (and communication/scheduling overheads of that auditing). Maersk operates across many different countries/languages and probably has different levels of technology in each of those countries that makes auditing difficult.