Unfortunately, given their affinity for testing things, the How To docs starting taking on that QA perspective and everything ended up in a QA "space". Sure, it's easy to move them around, but there wasn't a clear cut way on how to separate the "How To" from the "QA" - and then they left.
Since then, people add things when managers say "make sure that's in Confluence" and it ends up getting placed in the areas they're most familiar with, not necessarily where it should be. Add in the aforementioned lack of standards and no two documents look the same. Then we started using Confluence for devs to write Test Plans and QA to execute them - and now it just makes my brain hurt whenever I have to go in there.
Some of it is a cultural problem: we're email and Teams heavy and so much of our "documentation" is buried in those tools. So then we adopt something like Confluence to move our knowledge base to that, but finding stuff in Teams is a nightmare (posted in another thread on that). So now rather than having one tool to rule them all, we just have another half-baked attempt.
We're monolithic for the most part, so I'm not sure Backstage would help us, but the article mentioned Stack Overflow for Teams, so maybe that would? (insert relevant XKCD here on competing standards)
The stuff that's not autodiscovered can live right next to your code, in any repository, so devs can just update some YAML keys when they're making other changes.
You can lint the backstage changes as part of PRs
Also I've never ever seen developers consistently keep stuff up to date in Confluence. There's just so much friction in that interface.
Edit: This is a serious question. What is that value prop of backstage over confluence?