"Blockchain" in some sense can also be seen as a programming framework where you have a common set of functionality that people know how to work with and can gain a transferable skill set with. Similar to how MVC knowledge is to some degree transferable between Rails and Django.
So in that regard I wouldn't immediately dismiss a usage of a blockchain as pointless. Given that PoA chains are usually pretty efficient, there also doesn't seem to be an immediate downside to it.
An API would only be the _interface_, which just like with MVC isn't the same between a lot of different implementations of the same model and doesn't cover additional assumptions, like e.g. having a chain of blocks with a consensus mechanism to decide which chain of blocks to prefer over a diverging chain of blocks.
If you want to argue for an alternative to a chain of blocks you could of course do that, but in my personal experience if you consider all the requirements (multi-party, auditable, etc.) the usual argument of "you could just use a normal centralized database" falls apart and you end up with something that in some form or another resembles a blockchain (or something equally complex), so why not use a blockchain?
The standard definition of "blockchain" presumes that there is zero-trust between nodes and that anyone on the Internet can join the network. These properties are probably not what you want for most practical applications.
For most practical applications a git repo where you have some set of trusted notaries and at least M of N notaries must sign each commit is probably closer to what you want. (Or something that is similar logically but still does not fit the standard definition of blockchain, which again is trustless.)
I also prefer zero-trust blockchains, as they are more interesting ideologically and intellectually. I disagree however that the "standard" definition presumes zero-trust. In my opinion the only thing that is presumed is some form of consensus mechanism, which can also be a trusted one like PoA (proof of authority).
> git repo where you have some set of trusted notaries and at least M of N notaries
There isn't really much difference between a PoA blockchain and what you describe on a data structure level. The main differences here will be the mode of operation (active node vs. passive repository) and builtin support and optimizations for currency transactions.
If you were really inclined, you could probably implement a optimized git client/server that could achieve that (and I wouldn't be surprised if someone has done that already). What's the point in doing so tough, if you could just as well use an existing implementation of a PoA blockchain?
I would rather people learned the basics of RDBM's and concepts like "primary keys", "indexes". The kids these days depend on that stuff being hidden from them by CPU/disk speeds and ORMs. If they can't get the concepts of a technology they are most likely to encounter in their day jobs, what chance do they have with Blockchain, considering that it is NOT a trivial thing.
So in that regard I wouldn't immediately dismiss a usage of a blockchain as pointless. Given that PoA chains are usually pretty efficient, there also doesn't seem to be an immediate downside to it.