SQL is the industry standard for a reason, it's well known and it does the job quite well. The important part of any technology is to use it when it's advantageous, not to use it for everything. SQL works great for looking up relational data, but isn't a replacement for a filesystem. I'll try to address each concern separately, and this is only my opinion and not some consensus:

Most programmers aren't DB experts: Most programmers aren't "experts", period, so we need to work with this. IT is a wide and varied field that requires a vast depth of knowledge in specific domains to be an "expert" in just that domain. This is why teams break up responsibilities, the fact the community came in and fixed the issues doesn't change the fact the program did work before. This is all normal in development, you get things working in an acceptable manner and when the requirements change (in the lemmy example, this would be scaling requirements) you fix those problems.

translation step from binary (program): If you are using SQL to store binary data, this might cause performance issues. SQL isn't an all in one data store, it's a database for running queries against relational data. I would say this is an architecture problem, as there are better methods for storing and distributing binary blobs of data. If you are talking about parsing strings, string parsing is probably one of the least demanding parts of a SQL query. Prepared statements can also be used to separate the query logic from the data and alleviate the SQL injection attack vector.

Yes, there are ORMs: And you'll see a ton of developers despise ORMs. They is an additional layer of abstraction that can either help or hinder depending on the application. Sure, they make things real easy but they can also cause many of the problems you are mentioning, like performance bottlenecks. Query builders can also be used to create SQL queries in a manner similar to an ORM if writing plain string-based queries isn't ideal.