Most companies don't have specific needs. They think they do, but 90%+ of the companies out there are either building run of the mill CRUD apps or something barely more technically difficult.
Even teams that are building "run of the mill CRUD apps" need to be expert on the specific context and needs of their run of the mill CRUD app. If it truly is generic then it doesn't need to be built (and thus doesn't need to be tested or discussed on HN).
Also anecdotally, in my career, while I've seen lots of CRUD apps they haven't been the focus, the challenge, or the money maker for any of the businesses I've worked with/for. So I'll buy that 90% of companies don't need this advice because 90% (or more) of companies don't do software development at all. But for the ones that do, saying that 90% of them don't have specific needs rings hallow.
Do you have anything to back up the link you're claiming between not being technically difficult and not having specific needs? Interfacing with several dozen external services probably doesn't fit what you'd call "technically difficult", but making sure they don't break would count as a specific need.
What is your definition of "technically difficult", anyway? Is it something that links in the Tensorflow library? Something with separate transactional vs reporting databases that have to stay mostly in sync? Something that has to stay easy to update when regulations change? Something like I mentioned above, with multiple-dozen external integrations and contractual or legal penalties if they break? Is it things like the auto-level feature that hobby quadcopters have?
I have spent a good chunk of my life explaining companies why they don't need any special hand rolled platform - leaving hundreds of thousands of dollars on the table.
I guess parroting buzzwords is always more popular in this industry.