Implementation follows specification, not the other way round.
In an ideal world where "specification first, then implementation" (assuming software spec can be perfect which is rarely the case), then yes. But that has never been Bitcoin.
Bitcoin Core can have bugs too or have internally inconsistent code, but when it does, you want to follow whatever it does.
It's not ideal but the ship has sailed long ago on that one. There's no going back to the "specification first, then implementation" model. Not on a live, decentralized production network worth hundreds of billions of dollars.
This is true even if certain parts of btcd / libbitcoin / [INSERT YOUR ALT. CLIENT HERE] are somehow "better written" / "more sensible" than in Core.
In a distributed consensus sense, being correct is not the ultimate goal. Being correct relative to everyone else is.
Another reason to stick to Core for consensus is that consensus is so hard (and 10x more critical for a base monetary protocol), even Core must honor its past selves. The backward-compatibility requirements for Bitcoin is the most stringent among all software we humans have ever built to-date, if it is here to stay and to have an impact that we hope for.
In summary, IMHO people are applying old mental models and existing software practices to Bitcoin, but that's a huge mistake.
Bitcoin (as a software project) is an extremely special beast, and is the first and only of its kind. The old rules / practices might not apply.