I believe where people go wrong is treating Product Requirements Docs (PRDs) as a universal tool and using templates sourced from the Internet.
In reality, PRDs are driven more by company culture. When "product mindset" is more prevalent you can make do with bullet points, where it is not, one needs to document each and every minor detail to make sure important things are not missed or misunderstood.
It is also a function of scale, a startup with a small team does not need detailed PRD, as everyone is usually in sync, but if you are working in larger teams, or worse, the team is not taking "ownership" of the output, the PRD becomes a contract. This also happens when anything is outsourced.
That being said, the PRD, or any long-form document about what is needed, and why and why something is not being done is a good resource for the product manager to have at hand as a personal reference. Working on the documents is a process of shaping the product, but the document may not be the best tool to communicate what needs to be built and why.
The Best PRDs are designed in the language an organization communicates, and rarely can be transplanted across organizations.

PRDs are not a document, but rather a reflection of a company's communication culture. Depending on the size and ownership of the product, the PRD can be used as a contract or a reference for the product manager. The best PRDs are tailored to the language of the organization.

PRDs- Not a Tool, but a communication culture