To answer one of your questions: Compile time is included in the time limit.

time ./Main
477780698022288702207693909036914 ... <loooong sequence of digits> ... 565000500171153667779

real	0m1,983s
user	0m1,616s
sys	0m0,358s

This is theBee 1000 at my Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz. The problem seems to arise from failure of memoization at the CodeWars host. I use somewhat tricky memoization mechanism which allows pure code (in the sense of FP and Haskell) avoiding mutation of the underlying data structure (I use vector) on the surface. This type of memoization has robust support in GHC since very early releases, but this can be easily broken, for instance, by lack of laziness in the underlying vector. This is why I wonder how the program gets built at CodeWars including GHC options, vector version etc.

Your algorithm is likely not scaling well in terms of performance for bigger n.
My first algorithm would get the 12 sec limit when attempting this kata.
Turns out I had to take a completely different approach for it to scale better. My submitted solution on my i9 takes almost 5 seconds to compute "theBee 1000".
I benchmarked other solutions on the site, and they took between half the time, to double the time of mine.

Hmm, my Haskell solution computes all [2..200] values in 3.8 sec at my i5 core ThinkPad, but when I run tests only (5 values) here, it exceeds the time limit 12 sec. I wish I could see what happens at the CodeWars host machine! I use GHC 9.6.1 at my laptop, here is 9.2.5, but it's unlikely the cause. I also used Template Haskell in the solution and it could take more time to compile. Is compilation time included into the whole time limit 12 sec?

Yes, this looks better!