Some standards have staying power even though they have ugly or stale-smelling features. This topic is to explore the reasons for their stickiness and perhaps suggest ways to unseat them, if that is your goal. 

Generally any challenger has to be significantly better to unseat them, not just slightly better. Their ubiquity gives them a "margin of imperfection".
------------------
'''SQL'''

Alleged problems: SqlFlaws

Possible reasons for hanging around:
* English-like syntax makes it more approachable to non-programmers or power-users
* Standard updates keep improving it to make it GoodEnough, such as the welcomed WITH clause for named sub-queries.
* Complaints about it are fractured, such as "relational purity" versus syntactical expressiveness complaints. That is, not enough people hate it for the same reason such that any given replacement candidate doesn't make enough SQL gripers happy.
* For some reason, the industry does not welcome multiple query languages the same way it does with application languages. Thus, other approaches don't get road testing and exposure.
* Some alternatives may require completely new database engines rather than being a query language that can be put on top of existing engines.
** {You hit the nail on the head with this one. To stack a new query language on an existing popular database engine is to compile the new language to SQL and the database equivalent of AsFastAsCee rears its head. This happens to be one place where the difference between hand-written code and compiled code shows immediately. Never mind the fact the hand-written code will be recompiled by the database engine.}
** ''If a database engine vendor wanted to encourage multiple languages, they should create a lower-level "query assembler language" or the like for their engine and publish it.''
*** {I'd use it. There's been too many times the optimizer was being really stupid. (Same donor as "You hit ...")}
** [Speaking as a database engine vendor, a good reason to not publicly expose a lower-level "query assembler language" is that I become obligated to support it, without a clear benefit to me (read: it cuts into my profit and/or development budget).  Given that query language parsing and optimisation is insignificant overhead compared to query execution, providing standard JDBC/ODBC access is plenty.  If you want to create your own query language that works with my DBMS, write a cross-compiler from your query language to my query language.]

'''JavaScript in Browsers'''

'''HTML'''

[Under Construction]

'''Qwerty Keyboard''' (See QwertySyndrome)

Possible reasons for hanging around:
* Alternatives haven't proven significantly better in multiple categories (RSI reduction, average user speed, expert speed).

'''C Syntax''' (See ItsTimeToDumpCeeSyntax, ItsNotTimeToDumpCeeSyntax)

'''COBOL'''

[Under Construction]