I didn't it before 3.8. Read the docs. All of them--three times.
While this is absolutely a "best practice" I really think there is a pretty big divide here between the best practice and what happens In The Real World (strictly by number of developers). Between $DAYJOB, consulting/freelancing, and the internet/tech twitter/HN/etc, I've seen basically three groups:
1. FAANG, startup, etc. that probably follows this best practice "cattle over pets" methodology more often than not. 90% of developers do not work here. For the same reason you can't compare FAANG salaries to really anything else, you can't compare their tooling and infrastructure either. They're playing a completely different game than most people.
2. Indie developers who want to mess around with this stuff.
3. Boring companies with IT departments where you have to request VM resources and wait for them to get spun up. I worked for a place within the last decade where the idea of getting a VM provisioned for you in less than 2 business days was laughable. This was a publicly traded, multi billion dollar company with probably 800 developers, IT, and support desk folks on staff and did not make any money from its software directly (we were not a profit center).
I am considerate of the "well you should just" mindset when it comes to dev ops and infrastructure, but most developers don't work in that environment. If the company has never had that sort of expertise or expense before, it's a hard sell especially if it's coming from a developer who has never worked in that environment before. And truthfully, the last thing I want to do as a software engineer is become "the devops guy" and now be responsible for the VM infrastructure of the entire team rather than actually writing code.
Having the default behavior during a network partition be "whatever, just chug along as if nothing is wrong" is bonkers. Yes, the person who first set up the cluster should have read the documentation and gone over the configuration file line by line to see what might need changing, but... damn, that's a terrible default. Sure, some people's applications might value availability over consistency, but that's not the safest choice that follows the principle of least surprise.
Using a higher-level library to interact with the cluster is really good advice, in general. We used Kafka at my last company, and colleagues who actually knew what they were doing wrote a (simple) wrapper library that set things up properly for our cluster so clueless people (such as myself) could write producers and consumers without having to understand what all the fiddly connection setup settings did, and how to handle various edge-case errors. Before that, quite a few outages were due to producer/consumer misconfigurations.
Also I can't imagine running this kind of infra on Windows servers. That sounds like a self-inflicted wound (by "self" I mean the company, not OP specifically). And the idea of Windows Update running on a prod server ruining your day... what? IMO infra should be as immutable as possible. Patching/updating software on a machine should be a matter of spinning up a new machine with an already-updated image (that you've built and tested elsewhere), bringing those new machines into a cluster, and then decommissioning the old ones. When colos and dedicated servers were all the rage, that was difficult (and sometimes impractical), but in this day and age, with on-demand cloud provisioning, there's no excuse for companies that can use that sort of infra.