It's both. It's also because they don't require you define your data structures up-front, and have a clean, concise syntax with lots of sugar, and no compile times.
When you start a green-field project, you usually have no idea what the overall "shape" of the software will look like. You don't know what your data-structures will look like. You don't know what their lifetimes will be, or where they'll be accessed from. You don't know what functions you will need to write, or which ones will be leaf functions and which will be branch ones. You don't know which functions will end up calling each other. You don't know where code will be duplicated, where it'll be shared, and which subtle variations will be required in different places.
All of these are really important to learn to come up with a "proper" software architecture.
The value of a dynamic language like Python or Javascript is that you can just hack your way around these problems to make further progress. Forget a field in a data structure? Just add it in the code that computes it. Need a function to take multiple kinds of objects? Make sure they have all the requisite fields (adding forwarding properties/methods if necessary), and then just pass it in, Python doesn't care. Make a mistake in your module system? Just call the damn private method, the language won't prevent you. Have slight variations in behavior? Attach a closure to the function or data structure and invoke it.
All of these are bad practices for designing a major system with lots of developers, and yet all of them come up all the time when a system is young. The value of prototyping is that you can make more forward progress, ideally getting something up on the screen or even in front of users, and then you have a concrete laundry list of problems to fix in the next version.
I disagree. I use the compiler's dissatisfaction with my code to guide the refactor I need when my model is wrong. In a language with a good type system, the typechecker is like a built in set of unit tests.
I think the more general point he makes is about design, its hard to have the design nailed down from the beginning for most projects, why not hack something up quickly and in the process discover lots stuff that you probably wouldn't had thought of in the beginning. But if you know a language that lets you iterate very fast and you are highly productive in it, that it also has great library support so don't you don't have to reinvent the wheel all the time and lets you refactor just as easily then sure ;)
My point is that I can hack things up quickly and in the process discover lots of stuff without needing to be able to run the hacked together code, because typechecking it is enough to guide me in how to reshape it.
In dynamic languages you can also hack things together and run them (manually or through tests) to see how your hacks aren't fitting together right. I'm not saying untyped languages are bad, I'm saying that they are not inherently better for prototyping in my experience.
Libraries are important, but totally outside the scope of this conversation and I think its rude of you to raise an implication about them here. Everyone knows Rust is a young language and has the libraries that come with that.
Is this mostly because of the dynamic and interpreted nature of Python and Javascript or because of their library ecosystem?