Assuming you're doing some sort of strategy where the order book is important, like market making or hedging another position, it seems kind of dangerous not to keep a full book, no? If the market starts to move and your limited book starts to represent a lack of bids or offers, that doesn't seem to be a great idea at first glance.
In a product with a big tick size, to react to any single event you'll probably only need to know what's happening on the top two or three price levels (as it's super unlikely to move more than that in a single market data update). Then after reacting you can update your big, slow book and generate a new fast, approximate book from that, in preparation for the next market data update.
For crypto the network overhead and variance in the exchange probably makes the performance of the order book implementation irrelevant, unless it's horribly slow, haha.
Some exchanges are doing colocation and are investing resources to greatly improve matching engine performance. It's become a little better than when they were all written in Ruby and hosted on a cheap cloud service.
Ah that's cool. Still I'd be surprised if there's many that are deterministic enough that a microsecond or two of response latency makes a big difference.
