There are actually 2 equivalent problems, (voting) consensus and total order broadcast and solving one directly leading to solve the other.
It's quite difficult to do (voting) consensus like traditional Paxos correctly and quickly in the face of failures. Therefore, most systems (Raft, Zab, Multi-Paxos) aim to do total order broadcast instead, using a leader to sequence all operations and only fall back to (voting) consensus when total order broadcast is not feasible, like during leader election.
The perspective I have in the post is that Multi-Paxos and Raft and so on are still doing pretty much exactly consensus for each log entry, they're just sharing lock IDs/ballots/terms across multiple log entries, and having the leader reuse the first phase -- acquiring the lock, reading the existing state -- across multiple instances of the second phase -- writing with the lock.
I think this is compatible with what you're saying, but maybe makes them seem more similar than treating them as two different problems.
It's quite difficult to do (voting) consensus like traditional Paxos correctly and quickly in the face of failures. Therefore, most systems (Raft, Zab, Multi-Paxos) aim to do total order broadcast instead, using a leader to sequence all operations and only fall back to (voting) consensus when total order broadcast is not feasible, like during leader election.