Implementation and contraindications for OPTIMIZE_FOR_SEQUENTIAL_KEY
The optimization is implemented by applying flow control on the workers trying to insert to reduce heavy contention and convoys. The idea is based on an unfair insert mutex per scheduler and it can help avoid latch waitlist buildup and convoys as a result. When users opt-in per index with the option, OPTIMIZE_FOR_SEQUENTIAL_KEY, and then we do traffic/flow control on insert workers. Essentially, using an unfair-mutex per scheduler (at a HoBt level where the optimization is on) the flow control will allow only one worker per scheduler to enter the insertion code path that contends for page latches, so that we can reduce convoys and improve the scalability of concurrent inserts. Pam Lahoud provides all this detail in her blog post and I can find nothing in the functional spec or design doc that indicates changes to the current B-Tree algorithms.  Other solutions that were considered (one of which was leveraging an optimized form of reverse-key indexes you referenced in your question) have potential drawbacks, and most would involve fundamental changes to the engine. These other solutions may be considered in the future, but this solution provided a significant improvement without fundamentally altering the engine.

You wouldn't want to deploy this where you are not expecting or experiencing last page insert contention.