I've read three definitions of "cargo cult" and still don't know what it or your reference to it mean.

It's mainly meant in jest, partly, at how corporations tend to imitate what seems to work for other, more successful corporations. Ie. at one point after FB, everyone and their mother wanted to make their own Social Media platform. Before that, Web Portals were all the rage. It's often about good ideas, but doesn't always make business sense. Implementations often miss the mark, especially in the beginning.

The term comes from this, and uncovers a bit of the futility about the so-called benefits of playing the imitation game:

https://www.steveglaveski.com/blog/the-curious-case-of-cargo...

The problem is that in the fast-paced corporate world, you either make your own startup (and usually fail at that), or you have to play the same game everyone else does. There's simply not enough time and resources to get ahead at everything. Unless you go for the smaller niche, ie. embracing agility. Of course, everyone and their mother is Agile (tm) these days too!

You've missed the point. A company seeing what another is doing, and copying their idea and implementing it isn't cargo culting.

The key feature of cargo-culting is immitating another without understanding the why behind what they're doing.

Imitating is simply imitating. Many companies have gotten rich doing this.

Fun fact: Oreo biscuits are off-brand copycats of Hydrox.

https://en.wikipedia.org/wiki/Hydrox

Literally: it's doing something because others are doing it and that's it.

Developers have a massive proclivity to follow something simply because others have. We're talking everything from best practices to design methodologies to whether or not to include a semicolon at the end of a line. There's a reason for this: writing software is very hard to measure and quantify. It's not a physical thing like a bridge or an automobile. When we hear about some new paradigm/framework/language/etc. espoused by some blue-checkmark-wielding developer who works at Google, we pay attention because...he works at Google, and seems like a trusted figure.

Not saying this is good or bad, it's just how it is.

I fear the "for now" is shorter than we think.

I don't. This isn't the first time.

First it was accessible programming languages (BASIC, Pascal, etc. ~1970s/80s), then it was standard software (spreadsheet software, ERM packages, etc. 1990s), then low code/no code (early 2000s), then model-/requirement driven (Rational Rose etc., late 90s, early 2000s), in between it was visual "programming" every now and again, now it's back to low code/no code again.

As long as the mechanical systems cannot test requirements for contradictions, don't accept non-functional requirements such as performance or security and produce non-correctness proven results that even fail to compile or are syntactically incorrect from time to time, I have no fears.

The current situation might as well be a local optimum in which NLP/ML will be stuck for quite a while. It's really hard to tell, but I don't see any reason for starting to panic just yet.