No — there's no way to avoid the place and route phase for an FPGA, which is responsible for choosing where the components on the device that collectively implement your desired design are placed, and ensures they're wired together. Performing that task requires detailed knowledge of the silicon, and for high-end FPGAs that only can only be done by the proprietary tools the vendor provides. There are also many other tasks (e.g. timing analysis) that a tool like this wouldn't perform, which would also need the proprietary tools and silicon info anyway.

The goal of this project is to provide a better source language that various HDLs can target their compilers at. Currently, every toolchain de facto targets some subset of Verilog as its output language, and expects another tool (the synthesizer, also often proprietary) to map Verilog constructs directly onto silicon features, like multipliers — and those multipliers get fed to the place & route tools. This approach works, but it's generally brittle, because no two Verilog compilers behave exactly the same (among other reasons) so the contortions needed to map constructs reliably tends to require a lot of trial and error and weird rituals.

For the most part, it looks like it. I don't see how you're being more productive though.