I agree on your main point, in a weaker wording: 'LaTeX resumes/CVs rarely make sense', but not for the reason you gave, and I disagree with not using LaTeX in general for technical information.
The reason I think LaTeX resumes/CVs rarely make sense is that there are a number of HR departments that require them in MS Word format (often this is a SharePoint house and yes, I think that bizarre, but that is what I've found). LaTeX can be converted to Word doc, but in my experience always requires tweaking.
For sharing technical work, I think it depends on your audience.
A connected team with a decent wiki or document generation pipline authoring informal technical how-tos or status intended for the team only? Then some flavor of markdown (I prefer Creole) can make perfect sense.
Authoring anything for team external use should use a well defined community standard (rustdoc, rst, etc.) if what's being documented is specific to that community (Rust code, Python code, etc.).
Authoring anything of a more technical nature (papers, how-tos to be delivered to a client, CONOPS) should be authored in a pipeline that starts with a text based format, so that you can put it under good version control (opinionated, but SharePoint/Word do not count for that for me). I prefer LaTeX for that format. Some prefer Docbook, some DITA, and I've even seen a TOML version. This gets you version control, document section re-use, and fine-grained control over document layout.
Note I said should.
Some potential barriers to that are:
* Skillsets - the rest of the team does not know Docbook, DITA, or LaTeX and may be resistant to learn. This will make it a hard sell to management.
* Time - The project does not have the budget or scope to change how documentation is being done, according to management. In reality, this pipeline will save time in editing, and improve quality delivered to the client or end customer.
* NIH/NIMBY - Not Invented Here and it's more obstinate brother, Not In My Backyard. If your shop has always done it a certain way, then the team may be resistant to changing. Especially if the way it has been done is reflective of a Windows world (MS Word, MS PowerPoint). If management is part of this problem, move. Only partially kidding, but a good document pipeline will be a hard sell.
What do you do if you cannot sell a good document pipeline?
You could version control your MS Word documents in Git through conversion[1], but this means you might lose some of the little tweaks your manager did to improve quality/put their stamp on the doc.
Another option is that MS Word has track changes, and you may be stuck with a combination of track changes and SharePoint/Confluence versioning.
Another option, which I've never tried, is to unzip the MS .docx file into a folder (each .docx file is a zip of a bunch of files, most them text), git version control that folder, and re-zip it up when needed. Not sure how well git diffs will work in this situation though. My guess it probably not well, but maybe better than nothing.
[1] https://blog.front-matter.io/mfenner/using-microsoft-word-wi...