I personally stand for as little blackboxing as possible. So I'd say it's very important.
You have to know how your language behaves under most conditions to generate "optimal" code and be able to assert certain asumptions you will make.
classic for example is the reference behaviour in js for complex structure in combination with the event loop or in php my alltime fav ... the datetime object ... references can be a bitch.
you have to know your tools to waste less time on problems arising there and you can use multiple selfcontaining technologies.
For example knowing how: tsc/babel/webpack/gulp/grunt/phing/pip/npm/maven/composer/ant do work will allow you to keep the build system close to the language, so you can separate the concerns of the setup and keep it simpler.
Every node guy will know how node works but if I trigger explicit "./node_modules/.bin/bla" commands from ant or phing via commandline they will be confused because they're not used to look in the build.xml because it's not the natural place to look at.
These are basic examples, but I think that's why you should take your time to get to know your tools.
Frameworks are the same so you can actually decide, if using it makes sense in a certain context.