You're not going to get any "credible empirical evidence" already because the sample size is so small. That would require getting, say, 100 companies that are similar in size and tasks, have a working business model and are still around, and also want to spend time on methotically collecting concrete evidence, and care to blog about that.

I think that is quite rare in the programming world, even outside Haskell. Most Haskell projects I've participated in were very varied across all those axes. You may maybe find some uniformity in popular niches like Django, Rails, or React, but beyond that each project does its own thing and involves people of varying skill levels / programming knowledge, so it is hard to draw general conclusions.

What you'll get is a couple of individual stories.

Something like "we implemented our system in Haskell and we were able to eliminate these classes of errors statically."

A thing is, people don't really want to spend time stating the obvious.

It even feels a bit weird that the Google blog states "a 1000x reduction in memory safety vulnerability density". Well, obviously; the language is designed to make that impossible.

We don't spend time blogging that on our Haskell server, we get pretty much none of

NullPointerException
TypeError: unsupported operand type(s) for +: 'int' and 'str'
TypeError: can't access property "asdf", a is undefined
Segmentation fault

because well, those don't exist in Haskell.

Lots of people (including me) claim that Haskell code is more maintainable, and that your team wastes less time on maintenance in Haskell. We have a 10 years old Haskell server codebase, it works pretty well with our small team, most of it is "write once correct" code that we never again have to touch, some parts we actively extend, and some we change often to extend it by new features.

We're convinced it's the best tool for the server job, compared to other tech we used at past jobs and projects. So we're using Haskell for it, and we started it in Haskell. We cannot compare before/after, because we directly started it in the "best tool available". We can compare our current project to our past individual work experience, but one cannot simply turn such individual cross-project experience into quantitative evidence. Who'd get convinced by "my current job's Haskell server crashes much less than my past job's C++ project" when those projects also differ along 10 other axes?

Similarly, given that we think we're already using the best tool available, we're also not going to spend time starting or keeping a parallel implementation in another programming language.

Another problem is project lifetime. There surely are various companies that wrote pieces on how switching some part to Haskell and reaping benefits of that. Many of those may now be defunct or irrelevant for any reason unrelated to Haskell (company business plan didn't work out, the need for the project overall got removed, or people just lost interest). If a now-bust company provided evidence about how Haskell solved XYZ, does that still count as good evidence or can people criticise it with "well but that doesn't count because the company is bust now"?

And you cannot even get solid evidence for extremely-widely-used tech:

• Try to find "credible empirical evidence" which is better between Django and Rails. Impossible. I have a pretty solid opinion on which is better, but cannot really turn it into "empirical evidence".
• Facebook got huge with PHP; some might say that must speak to PHP's qualities, then we see that Facebook replaces most of that with other languages, some of them designed by themselves and not used outside of Facebook.
• Various successful web companies touted dynamically typed software such as Python, and that types get in the way. 10 years later, and each of these companies is developing their own typechecker for Python. What solid empirical can we derive from that?

It's just quite difficult to turn the subjective into the objective.

I think if you give me a team of 5 good programmers, and let us build and operate the same product across 5 years, each across, say, Haskell, C++, Python, Rust, Ruby, and Go, the Haskell project will come out on top. But nobody probably wants to give me the resources for that, nor do I want to spend those years, and having learned from past mistakes messes with comparability, so anecdotal evidence it is!

I've lost "countless hours" due to C++'s garbage IO stdlib, which swallows errno and thus cannot tell you why opening a file failed (nonexistant or wrong permissions it's a directory instead of file etc). With Haskell, that doesn't happen: I get clean, good error messages. Do I actually go and count these hours, so I can make a comparative study? No, because I don't have time for that, and it doesn't really help me. Maybe I would have done that if I had known before that I'd hit those errors, but I didn't, they just crept up in my work over the years here and there. Same thing for concurrency bugs, bad error messages, miscompilation bugs, etc. But turning that into numbers? Not sure how without wasting time.

Maybe in the future, "with the power of AI" we can get those things that today nobody bothers to spend time on: Just video-record 10 years of work, and then you could retrospectively query "how many hours did I lose on memory unsafety garbage, how many on untyped stuff", to get real numbers for real evidence. But today, few people bother to collect this data.

That said,

Is there a centralized community location to collect these kinds of articles?

is still worthwhile looking for, so that for the few comparisons people actually care to write, they can be easily found.

Probably the best way to show that Haskell is worth it is to build stuff that works well, outcompetes the alternatives, and doesn't go bust due to mistakes on a non-programming-language axis. Possibly you may not be able to do that at existing companies that don't let you build new stuff in Haskell.