A proper hash function provides a lot more than a timestamp. A service with a B-tree (or other traditional database) can rewrite history. Even if have a copy of the db, it's difficult to prove that your version is the service rewrote their version.
If a service wrote all transactions into a log in a way that allows for easy verificatio9n of the validity (including order), and the parties using the service regularly check that log, those parties can demonstrate that the service is acting correctly.
Questions about transaction order and consensus are separate problems, which may not be necessary, depending on the nature of the service. The point, I believe, is that some problems only need some of the features usually associated with "blockchains". We are only beginning to find the interesting uses for Merkle trees, and thus shouldn't blindly use the current bitcoin-style design when the current problem could use something similar,
