Software projects famously suffer from unforeseen complexities that slow development and undermine teams' ability to execute on high level objectiv...
For further actions, you may consider blocking this person and/or reporting abuse
Interesting subject.
SQL is simple. In itself it is rarely used at all, usually implementations come with support for variables and whatnot that put them apart from the original QL.
It isn't well suited for all common database tasks either. There is good reason to use column or graph databases too, and they tend to have other types of QL:s. Picolisp makes use of a prolog-like inference engine while kdb+ is queried through APL-like languages.
Also, being popular isn't much of an end in itself. It is a way of measuring software quality that haven't been particularly accurate. The JRE is very fragile and Java is arguably among the least pleasurable and effective languages to work with, but it is still one of the most used and most popular in industry.
Personally I'm not so sure non-fragile software is possible on the hardware we're using today. The branch predictions that squeeze out Ghz:s and lifted us above the architectures of elder times comes with great vulnerabilities, the end of which is nowhere in sight. Some embedded systems are more reliable, of course. But 'the cloud' and mainstream devices are not.
So I would probably recommend to use and invest in simple technologies that allow the most expressiveness and the fastest development, to keep the attack surfaces as small and fast changing as possible, rather than aim for some development methodology or other, or some fairly arbitrary principles. The JRE will be brittle forever. It is that complex. SQL will always have performance issues in real applications, because they are complex and make demands that such a simple and portable QL must handle by extensions it cannot express itself (hence adding complexity, always).
React hasn't been used for long. It is quite ad hoc and tailored towards a particular business' needs. This doesn't change due to the company using it, rather it is just two sides of the same coin, and allowing project owners rather than issue owners control development doesn't affect it either. The company's business is also what drives their maintenance, if you find a bug in a marginal case that they will never run into it is entirely arbitrary whether they fix it or not. Or perhaps they restructure their business due to changing markets, and then also their libraries and make breaking changes. You will then need to replace them in your projects, since they are too big and too complex to be rewritten or maintained easily.
Scheme is simple and reliable. As are WAM-based languages, like miniKanren and Prolog. They are flexible, easy to understand and has endured for ages, much longer than frontend web development has been a particular job. Still, they aren't used much in industrial applications compared to, say, Java or some other clay colossus that stagger around and litter with CVE:s. This is due to the cost of educating and thus for replacing workers, and as it happens, this is also why trends and advertising in software development gets such influence over jobs in the industry. Rather than, say, longevity or reliability of application dependencies.