Which isn't really much of a conflict. You can prove out your thoughts in a scripting language, and after the dust has settled you can move the workload to a systems language. Different jobs, different tools.
I guess if you're one of those weird religious types that insist there is only one true God (read: programming language) you might feel conflict, but nobody else cares.
And possibly different programmers.
Say your a (non-computer-) scientist. It is not (typically) part of your job to learn Rust or Haskell.
You might want to learn Rust if you are so inclined but many scientists are not.
Anecdotally, I work with a lot of scientists and they only write scripts. When systems are needed, they hand it off to the development team. Anyone can fumble through scripting, but there is a lot more to think about when building systems, and that's probably not something most scientists want to put effort into – for the same reasons they probably don't want to learn Rust.
Realistically, learning Rust is the easiest part of becoming a systems programmer. But there is little incentive to learn any system language if your workload is always scripting in nature. You are going to, rightfully, reach for a scripting language.
Why are they "conflicting"?
Common Lisp could do both quite well.
A scripting language would seem to be good for the exploratory scientific research, because of that. Whereas when you need to create a performant library that can do heavy crunching with reproducible results on any platform you need the other. The questions is: Do you know what you want to implement, or is that still an open question?