These issues were obvious much earlier than that. I looked into Elm and was excited about it initially, in either late 2013 or early 2014. Then I looked into the history of some of the design decisions that baffled me (such as lack of type classes) and concluded the project was poorly conceived and led. The leadership didn't respect the opinions or capability of its end users.
This was the major sticking point for me when it came to Elm. I invested a lot of time into Elm and even published a few packages. Many things contributed to my giving up Elm, but the final straw for me was when the core team removed some userland APIs under the guise of "we can't trust developers not to use these to write bad code". Myself and several others tried to convince Evan to reverse this decision, to no avail.
And the package website is just an index, the sources need to be on github in the first place (this has some problems too), but if the website is down, you can still grab them from github.
https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#why-d...
I don't want to know what would ever happen if the Elm developers decide to take https://package.elm-lang.org offline. That will leave so many projects out there in an unbuildable state. Even if you saved source tarballs of the core packages, there is no way to tie it into the build yourself. The Elm compiler must load it through the official package site.
I would thus personally strongly advise against using something like Elm to build any piece of software that needs to be maintained over time. It's too much of a risk.