It can be non-concensus up to a certain level, there's a few things which are better done natively as it has a much better user experience and less chance for errors.
In the example of steemmonsters, when a users A and B both simultaneously buy a card from user C, only one of them will receive the card, but both will pay.
This can be avoided by either locking the card for a certain time before allowing a purchase, or by implementing the marketplace and token tracking natively, which would not require any locking.
I don't think your specification involves any purchases using Steem -- that is where soft-consensus falls short, when transfers with Steem must be incorporated into the DApp (I do have a solution, though, but it is quite complex and involves pegging a token running using soft-consensus to STEEM). Anything other than incorporating STEEM transfers, though, can be done using soft-consensus.
But is there any part of your specification that actually requires native consensus? I haven't read through it all, so sorry if I am missing something.