Poor documentation can be as much an asset as a liability, depending on your perspective.

- The more comprehensive your documentation, the easier it is for your competition to get a complete read on your product and it's capabilities. Which makes it both easier for competitors to strategically outcompete you, as well as counterfeiters to more accurately counterfeit your chips.

- The more precise your documentation, the more stringent your customer's expectations become. Poor documentation can act as a form of liability insurance - if someone uses a feature and things get weird, you can claim their use is out of spec. Harder to weasel out if things are clearly documented.

- The more expansive your documentation, the less dependent your (potential) customers will be on actually talking to you when evaluating if your product is fit for their use. I could see this being a negative in this industry - Feature X may be fine to use, but introduce intermittent instability if used for extended periods of time simultaneously with Feature Y, which can be compensated for via Z but doing so shortens expected lifespan by 30%. Wargaming out every possible contingency ahead of time would both be extraordinarily expensive, and result in documentation that would overwhelm the people using it. But not doing so while providing otherwise expansive/comprehensive documentation may lead to a false sense of understanding from your customers such that they write you off when your product would have in fact been a good fit.

- A corollary to the above - poor documentation trains your (potential) customers to just reach out directly and have a conversation about it. Which provides the chance for you to truly evaluate their situation and provide a more considered response that takes into account their use/circumstances. Which can either be using the product they may be familiar with, or suggesting a different one that's more appropriate that they may not have thought of.

- Ditto the above for implementation. Directly supporting them during their implementation can be more effective than them relying on generic documentation, since you can provide more contextually relevant details/instructions/direction. Which cycles back to the second bullet above, where you have the opportunity to provide information that steers customers in the right direction, addressing potential issues preventatively rather than playing damage control if their use wasn't completely aligned with the documentation they blindly followed. You can also directly put the costs of this work against the customer, rather than eating it via the comprehensive wargaming scenarios mentioned above. Which sounds harsh, but is far more efficient for everyone involved. Customers with a cookie cutter use case get cheaper per unit prices since you didn't inflate the amount of QC and experimentation required to flesh out the documentation, and you didn't waste time and resources chasing down contingencies that were never actually applicable to any of your customers.

So it sucks for a subset of people - hobbyists who aren't direct customers in the first place, cash strapped hardware shops who can't pay for that support, and the engineers at BigCos who aren't willing to pay for that support. But can still be rationalized when you consider it's an absolute non-issue for their primary target market, while also indirectly benefiting everyone else via the lower unit costs afforded by this mentality/approach.