We provided a really nice walkthrough to get you going as a quickstart. The whole point was originally to keep it simple so that you have to be thoughtful about the settings and tradeoffs you make in terms of reliability vs performance. I didn't want to be overly prescriptive in what and how teams use functionality like transactions and idempotence.
But we find, time and again, people get this wrong. They don't look at things like delivery reports, they don't set timeouts that make sense, they often don't even think about their replication factor. I pushed against full fledged client examples because there really isn't a one size fits all and I didn't want people to copy and paste without thinking about what they are doing.
The reality is, I am fighting a war on drugs. People want things to Just Work, and don't have the time to sit down for a day or two and read a book on kafka concepts (which we provide for free) and just want to get things done. We will repeatedly be involved in "outages" because clients could not tolerate a broker restarting and they did not configure their apps to be resilient.
On a more topical note, a guy on my team wanted to rewrite a python app we have in kotlin about 2 years ago, because it was the hot thing for about 5 minutes and our little POC python app was getting unwieldy for the scale it was growing into and its complexity. But we had no one in the firm who knew this, no support network for this, and I kind of saw that this was likely to be a flash in the pan kind of thing. I had to say no, and he was all pissy and was like but JVM! and arguments like that. I am really glad we didn't go that route, because kotlin is all but dead, and that guy left after about a year, and we would have been left high and dry.
My larger point is- what seems like such a cut and dried correct answer when its just from your viewpoint, can look very wrong when put in context of an organization, but unfortunately the end perception is often "my boss doesn't get it."