That is indeed one case where a large single-node database makes a certain amount of sense (though it's not the only solution; you need a globally consistent answer for which orders match with which, but that doesn't have to mean a single database node. Looking at the transaction numbers I'd assume that e.g. the busiest books on NYSE must be multi-node systems just because of the transaction rates). But fundamentally there are what, 11 equity exchanges in the US total (and less than half of those are high-volume). And the market fairness requirements are very specific to one particular kind of finance; they're not something that would be needed in healthcare, general enterprise, or most financial applications. Like I said, niche.
Financial systems especially trading platforms need to ensure market fairness they also need to have at the end a single database as you can’t have any conflicts in your orders and the orders need to be executed in the order they came in across the entire system not just a single instance.
This means that even when they do end up with some micro-service-esque architecture for the front end it still talks to a single monolithic database cluster in the end which is used to record and orchestrate everything.