Very fast (faster than naive assembler) but not at all high-level; having to look after the stack is a bit of a pain. Writing your own FORTH is fun - it doesn't need to be in assembler - I once wrote a FORTH-like scripting language in C++.
Every Forth that uses conventional threaded-code interpretation pays a considerable performance penalty, execution times are likely to be very roughly quadruple the equivalent assembly. [0]
Forth's runtime performance can be competitive with C if 'proper' compilation is performed, though. [1]
[0] https://benhoyt.com/writings/count-words/
[1] (.fth file with their results in comments) http://www.mpeforth.com/arena/benchmrk.fth
I'm curious if anyone has tried using futamura projections to do this in stages. I hadn't known about them when I last built a forth and it may yield more satisfying, incremental results than the last time.
Depends on how naive the assembler programmer is, and, I would think rarely, if ever, on modern hardware because the many subroutine calls kill branch prediction benefits. Also, on lots of old 8-bit hardware, defaulting to 16-bit integers will kill performance relative to native assembly in cases where 8-bit integers suffice.
(Of course, you can fairly easily replace hot loops by assembly or (more difficult) change the forth compiler to compile parts to native code, fuse words, etc)