Nick Gnidan from Truffle wrote a beautiful blog which answers this.
While having a single, centralized registry can be convenient for discovering new packages, there are some downsides, such as a limited feature set and maintenance overhead. ethPM v3 uses a federated registry model to overcome these limitations. In a world where code controls large amounts of money, malicious packages pose a serious threat. Forcing package authors to deploy and maintain their own authorized registry minimizes the chance that a malicious release finds its way into a popular package. Furthermore, the overhead of maintaining a central registry is significant, and more sustainable if distributed amongst package authors. Finally, defining a standard which can be extended allows devs to write custom logic into their package registry to achieve whatever goal they have in mind allows for new ideas to be experimented with and bloom.
ethPM v3 made breaking changes from ethPM v2, so unfortunately ethPM v1 and v2 packages are no longer supported by the majority of ethPM tooling. However, upgrading a v1 or v2 package to v3 is simple with the ethpm-cli.
While package authors should take their own measures to ensure IPFS assets maintain availability, the Ethereum Foundation sponsors a server that will automatically scrape, back-up, and persist IPFS assets published to any ERC1319 compliant ethPM registry.
Glad you asked! The easiest way to contribute is to package up your smart contracts, and make them available to the community by releasing them on your registry. Otherwise, pull requests to any of the existing libraries or integration into new frameworks would be massive - and earn the eternal love & appreciation of the ethPM community.