If you build a state machine on top of a relational database you can abstract concurrency problems away from your business logic and allow developers to write safe-by-default code without dealing with concurrency concerns. This post explains how to build a library that offers those protections, and how they work under-the-hood.
I guess separation of concerns? One is for the system, one is for display?
A unique Boolean is easier to query than sorting and limiting?
Maybe you don't ever need the ability to display a history, but you still want the history (instead of just making the transaction_id unique constrained)… so you just drop the sort_order column?
I understand what you are saying.
Maybe that's just how they went about it. Originally planning on using created_at to do the ordering, then later realising that a customisable sort_order is required so they can make things make sense without having to fudge timestamps.