I think it's important because good KM practices ensure that teammates/employees are able to autonomously and asynchronously capture, organize and share knowledge. So that they can do their job faster and more efficiently.
On the other hand, the term "feels" so old and outdated that I don't think anyone is actually creating a process for this.
The few profitable start ups I've had the pleasure to work for (including the current one I am at) heavily leverage confluence. A well structured confluence/runbook is indispensable in quickly ramping up engineers new to the company or handling common bugs/etc if you find yourself on call. There's never been a formal "process", but generally if you're doing something that is complicated enough that it can't be explained to someone in passing you make a new page and start writing. I personally do this by the seat of my pants. If I feel like the bus factor is high I will generally start writing stuff even if only I use it, so on the off chance I get hit by a bus there will be documentation somewhere about how to do things. But, I also religiously take notes for myself (ADHD is one hell of a drug) and I've found this alone a major contributor to making it to staff.
Confluence is just one solution though, I've also seen this done with a simple git repository and a well written front page README.md with URLs to various things, or having project specific knowledge in a special file along side the project README.md.