> Why do we have a BIP process? 

All ideas for Bitcoin clearly don't need and shouldn't have a BIP. If a wallet developer has an idea to improve say the graphical user interface (GUI) for the wallet they are working on there is no need to formalize this idea in the BIP process. Even if it was wildly successful and every other wallet in the ecosystem ended up copying the feature there are no cross compatibility issues. Every wallet can independently choose whether to implement the feature and make tweaks to the feature without impacting the broader ecosystem. To encourage other wallets to implement the feature the developer could document the feature in their wallet repo or a design repo like [Bitcoin Design][1]. Developers are free to experiment and implement the ideas without interacting with the BIP process.

However, there are examples where you either need the entire ecosystem to converge on a single standard/specification or at least it would be strongly preferable that they do. The most extreme example is consensus rules. Unlike the wallet GUI example, if two Bitcoin implementations experiment with different consensus rules on mainnet then they can split the network and create two blockchains with a shared history. A formalized BIP process brings additional scrutiny and clarity to an emerging (and ultimately finalized) proposal separate from any particular Bitcoin implementation.

> It seems like unnecessary centralization and introduces gatekeepers (BIP editors) and bottlenecks.

Agreed that these would generally be considered downsides. If the upsides of the BIP process were non-existent (or minimal) then there would be a strong argument to discontinue the BIP process. I would argue though that the upsides discussed above strongly outweigh the downsides. Not only for consensus rules but for any examples where a single standard is preferable to every party in the ecosystem implementing entirely different approaches.

> If something makes it into Bitcoin Core and/or other implementations and users run that code then surely whether it has a BIP or not is entirely irrelevant.

There is an argument for this but as discussed [here][2] we don't want to hitch Bitcoin's security and consensus rules to a single implementation permanently. There is no cast iron guarantee that Core maintainers and contributors will act in good faith and not unilaterally make (or resist) consensus rules changes against the wishes of the broader community for the rest of Bitcoin's existence. (To be clear I don't think this is a current concern but stranger things have happened when you consider the entire course of human history.)

> Similarly why should proposals be stored in a single repo? If I want to propose an idea for Bitcoin I'd rather just store that proposal in my own repo than submit it to the BIPs repo.

As soon as you introduce multiple repos you introduce the prospect of multiple sources of truth and multiple sources of reference. Some repos will disappear or not be maintained. They may store an outdated version of a particular BIP and then readers of that outdated version would get an inaccurate perspective of the current (or finalized) state of that proposal. The upsides of having a BIP process (focusing review and scrutiny on a single document in a single repo and offering clarity to the readers of the finalized specification) are abandoned.


  [1]: https://github.com/BitcoinDesign
  [2]: https://bitcoin.stackexchange.com/questions/112365/does-the-reference-client-bitcoin-core-determine-the-consensus-rules