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.

The Bitcoin Core source code that does consensus is the specification.

Making that spec be written in English rather than C++ won't make Bitcoin more decentralized, as the centralized debate would just be on two levels. You can't fight reality: computer science is yet capable of getting two different code bases to agree 100%

The reason many people insist that Bitcoin should have a single implementation is that Core has been captured (clear to anyone who witnessed the block size wars), and multiple competing node implementations would challenge their current total control over the network. As it stands the only time the network has seen a change of primary developers was when the current core cabal essentially performed a hostile takeover of the core repo, kicking out the original developers through the use of incredibly impressive social engineering and PR. Unfortunately the tactic was successful and now many apparently free-thinking humans believe that only core can lead the project and the possibility of the free market choosing which software to use is blasphemy.

Nope. The bugs are in validation code added on top of deserialization; actual deserialization wouldn't have those issues.

Lightning isn't a consensus system, so multiple implementations probably do improve overall reliability.

Basically, my LN node can disagree with your LN node on most things without all hell breaking loose. That is not true of mining in a consensus system.