To understand the appeal of dynamic languages, it's critical to consider the era they came from. Your statement is not true of the general programming landscape ten years ago. It's not really true of the general programming landscape today, for that matter, which is still by sheer mass C++ and Java. But 10 years ago, there weren't hardly any choices of statically-typed languages that weren't a bit of a bear to use. 1990s C++ is a monstrous nightmare. A lot of this monstrous nightmare was arguably the programming environment (Windows, Xwindows, UNIX, everything was a bear to program in back then), but when you took battle-scarred C++ Windows programmers and showed them

    print "Hello world!"

I think there's a general trend towards languages that either make the static typing easy enough to use that you don't feel like you're losing out on much, or make the static typing pay for itself better (Rust), and I think that will continue to be the story for the next ten years on the developing language front. I think it may be the case that if they weren't already entrenched, what I call the 1990s-style dynamic languages (because it's not just that they're "dynamic", Perl, Python, Javascript, and Ruby are almost the same language, compare with the "dynamic" Erlang to see a major difference) wouldn't succeed if someone wrote one for the first time this year. In fact they'd probably take a beating for the performance issues it would have. But they are entrenched and have over a decade of refined libraries, support documentation, tutorials, and of course, the big hitter, existing code. So they aren't going anywhere any time soon.

The other thing is tooling. There are lots of hardcore developers to whom even syntax highlighting is too much distraction, let alone error checking, auto completion, etc.

Well... To say the least I am not one of them. In fact to me, a large part of the simplicity of a language resides in the interaction with the IDE, the feedback it gives you on what's legal and what is not, where you may have a bug or an ambiguity, what can I do from there, etc. Dynamic languages defeat advanced and proactive tooling. And to me it makes them actually quite hard to work with, not self-discoverable, and all-in slower to develop. The time not spent writing a class or a return type ends up being spent on the reference page of the library (after you checked this is the correct version) checking what are the arguments of a function, etc.

First, there aren't really any compiled languages where the syntax is similar in ease of use to Python (or any other popular dynamic language I'm familiar with).

All the compiled languages with which I'm familiar require a significant amount more work to accomplish the same thing; C apps are full of boilerplate to detect error cases, allocate memory, check buffer lengths, etc.; dynamic languages handle this for you so the total amount of code tends to be lower.

Writing a simple program to test an algorithm or proof of concept is generally significantly less code, the code/test/debug loop tends to be significantly shorter, and you can often get to a solution significantly quicker while avoiding the typical bugs that come with lower-level languages.

Python also has a pretty substantial standard library which is easy to learn and use and very consistent, meaning much less copypasta code or external dependencies.

On top of that, a great deal of use-cases for languages like Python aren't CPU-bound, but rather I/O bound (disk or network). In cases where your app is CPU-dependent, it can often be trivial to replace that inner loop with optimized native code written in C or other languages, while still keeping the rest of your application easy to read and maintain.

Lastly, for complex algorithmic work, there's a lot of packages which implement standard data structures and algorithms in native code and provide usable, idiomatic interfaces in Python, which means that for a lot of things you can work in native code with the ease of Python, at a minuscule performance hit but a dramatic increase in programming efficiency.

Now if you are not doing something that requires performance, I think there is still a good case for static typing: advanced tooling. Dynamic language limit a lot the ability of the IDE to help you finding bug, making the language and the API self discoverable, auto completing the code, providing advanced analysis (who calls what) or refactoring (rename a property). Some people do not need that, but to those who rely on that, dynamic languages must really be easier to write by an order of magnitude to end up being faster to prototype.

If I was suggesting a language to a beginner, I would push for a language with a strong IDE.

With a dynamic or duck type system, though, you can avoid a lot of writing out interfaces or making class hierarchies. You end up with something less structurally uniform, but with a much shorter time to get results.

If you care about type mismatches, use a statically typed language. If you just want to get something working, use a dynamically typed one.

Swift looks promising in this regard.