The whole point of testing betas is to find out what's not working from a wide pool of users. No software company can test ALL the possible scenarios in-house, there are just too many variables. Initial testing is usually done with clean environments, and public testing brings in the real world: people with different software, preference settings, and ways of workin which exposes issues that just don't happen in a lab environment. If those people don't report back then their problems won't be prioritized as highly, simply because the company won't know how bad the problem is.
My team at work administers a Mac beta program populated by a few hundred volunteers across the company. We test macOS releases and various software titles that we deploy to our employees. They help us get ahead of those issues that would affect tens of thousands of employees by reporting back to Apple, Microsoft, etc. and providing then with feedback and diagnostic data so they can fix those problems before general release. We also get to comment on what we like or don't like before those things get baked in - it's usually a lot easier for the developers to adjust something while they're building it out.
It's a vital service (and a very successful program) but it's not for everyone. We make it clear up front that, before you join the program, you have to comfortable dealing with unforeseen problems while doing your regular work, and you need to be able to roll back on your own or even rebuild your system from scratch in the (relatively rare) event something catastrophic happens. It's the same in this case - you really need to be willing to take on those risks before jumping on the beta train. It is great fun to see all the new shiny stuff but it's also a gamble every time you update. If you can't afford the risk - which is the case for most people - then you should stick with production releases.