Besides specialised languages for UI, and logic. Does anyone build custom DSLs for each application or industry?
Good programmers have long known that you should build your language up towards your application, and then write your language within that language. What tools are available to do that and where the line is drawn will vary. But you'll find customized languages buried in your database (SQL), configuration languages like https://github.com/vstakhov/libucl, specialized build configuration languages like make or ant, regular expressions for text matching, and so on.
Some languages encourage building external languages that you then parse and act on. Others encourage customizing an existing language to your needs. (Our Glorious Leader published a book in the mid-90s on doing that with Lisp, see http://www.paulgraham.com/onlisptext.html for details.) There have even been languages which are designed to be easily implemented in other languages, with whatever customizations you want. For example I personally worked with code from the 1980s that implemented a Forth variant to write financial models in.
But the idea doesn't have to be literally a new language. Squint sideways at any API, object model, or library and you can see it as a language. Conceptually there is a close parallel between scripting web services, and writing a TCL script that uses prebuilt commands written in C. If you can see the parallels and see how principles from the one apply to the other, the odds are that you'll be doing both better. Whereas if you don't see it and reinvent the wheel from scratch, you're going to wind up learning lessons the hard way that were learned many, many years ago.
All that said, writing and maintaining a language is significantly harder than writing business code. Therefore you'll always see rather more people writing code in languages, than writing languages to make code easy to write.
All that said, writing and maintaining a language is significantly harder than writing business code.
The same can be said for writing good APIs and libraries, isomorphic to your second point.
The DSL "philosophy" as presented in for example The Pragmatic Programmer from 2000 was that every programmer should write his or her own domain language as the situation requires. That every project should come equipped with its own language, codifying that business problems business rules.
That philosophy, and the surrounding hype, has completely died down. Put simply, it wasn't a good idea. More languages makes it harder to communicate, not easier. Plus, writing a good DSL that someone other than the creator of said DSL can understand is tons of work. Instead, what one aims for is generality.
I agree with this in the main unfortunately ... I was a proponent of DSLs and did my best to try make them whenever practical. The only pattern that’s worked out for me is the builder pattern. This doesn’t require much work, and you get something functional that works as you might expect that people appreciate.
Again ggplot, epic example. Other examples , Varnish, Dockerfile, Nginx, ufw, etc
Personally, I tend to use them quite a lot in my own projects. These aren't commercial (and often aren't released at all), so might not count. Still, it's very handy to be able to embed a DSL into a complex project to provide programmability, and most of the modern scripting languages tend to be too large and/or too slow for my purposes.
My DSL of choice for this tends to be TCL-based, as I can easily extend the language in task-specific ways and drop the parts of the language that aren't useful for the task at hand. This results in something capable, tiny and fast.