You kind of are in a very wrong path.
But you also aren’t.
Why?
Normally. You perform tasks in a separate thread.
Be that a dedicated cpu core or the gfx or whatever.
It’s not the game thread.
Therefore the fame FPS is unaffected.
However.
Spawn actions require you to act on the game thread.
As such, even setting up a multi threading system wouldn’t really help.
Now.
Adding a delay node won’t do anything at all except wait for execution to be allowed.
This is bad coding.
Since the engine is full of it (bad code that is), we sometimes resort to it. Whatever works.
Doesn’t mean this is the correct way to do things.
Adding a timeline
Every tick, is just going to mean increasing the execution stack without any real benefit.
async manager
Is a completely different and viable pipeline. But I doubt it’s blueprint.
It is a much more proper way to do things.
It is kind of similar to setting up multithreading but it would actually work - you need cpp for both.
The only other option is for you to set up a blueprint Spawn manager. You set the manager to handle a Pool.
Pools are a fairly common concept.
You keep count and manage how many instances the engine can safely batch at one time.
As well as their removal.
The extent of a management pool is whatever you code it to be.
It can go as far as tick aggregation if needed (the manager runs the tick function for all the actors it manages so that the function cost is much lighter instead of having many tick functions).
For your specific case- spawning cubes.
You can set the manager to Spawn a variable number of cubes based on delta time.
The lower the frame count the less it spawns.
A maximum value needs to prevent people with high fps from getting swarmed by cubes.
Obviously there’s much more to this, such as how you Spawn things, and what their position is defined by/calculated.
The calculations - for instance - could be done in parallel via multithreading if needed. Or they could probably be simplified and done “on begin play” as part of the loading.
Storing the calculations and using the stored values is essentially “costless” when it comes to runtime eval. But their cost has to take place somwhere in the pipeline.
USERS are generally OK with paying a loading cost up front. So that’s what we all generally set up.
Running a custom manager “spawn” function per tick, you should be able to limit the number of spawns per tick natively.
The function (or event) will only run once and Spawn whatever you told it to Spawn.
Note that this isn’t the best solution. But it is easily achievable in blueprint only.
If you want to be fancy you can set up an interface for it too.
You will still hit the game thread when you use “spawn”.
As such. Using the game time to limit the number of spawns could throw off iterations.
You manager and pool have to be coded to account for all dynamic variations possible. Including game pause. Probably.
" to "wooow its so fast and I now can calculate hundreds of thousands more things now, infinite possibilities 
"