The same with Clojure, suddenly you start writing Java with parenthesis.
In the JVM, if you want absolute control over performance its better to just write Java for those parts (don't know much about Kotlin).
There is no reason compiling things should not compile at similar speeds to chez unless you are telling your compiler to ootimise everything.
C++/ruae are just exceptionally slow and it became the new bottom line somehow. I know rust does a lot of housekeeping, but after using chez and sbcl, 45s for a 1.5kloc project is killing me inside.
.NET Native, D, Delphi, Ada and Eiffel also have pretty fast compilers, while offering quite powerful languages.
Lets even pick Turbo Pascal 7.0 for MS-DOS, which was quite feature rich, and was able to compile very large programs in a couple of seconds.
Also Visual C++ with modules preview support, incremental compilation and linking is also reasonably faster than the FOSS alternatives.
It is only a matter how much money one is willing to invest into improving tooling support.
I have noticed this with every "X produces code faster than C": you begin with two programs that use a suboptimal algorithm, then you take your non-c language and try to write C in it. The result is always awful and removes most reasons not to use C in the first place.
This has somewhat changed with rust and in some sense C++,but for other languages my point still stands. They have a nice idiomatic golden path that is fast enough for most cases. Once you need performance badly enough you have to treat you language as an assembler, and then you will always lose to languages that actually are good at that.
I say this as a scheme/Haskell weenie. Writing really performance scheme and Haskell code often means writing ugly code.