Did you test the latest bugfix-2.1.x code?
Yes, and the problem still exists.

Did you really?
This is problem with leveling because 10mm is deafult FADE_HEIGHT, so try UBL too. Maybe bilinear didn't like junction deviation at that point. Also check slicing resolution and gcode - i suspect a lot of stupidly short segments, like 0.001mm

Yes I tried bugfix-2.1.x

Also why doesn't this happen with version 2.0.9.3 and it does with higher versions?
Version 2.0.9.3 prints perfectly so slicing and gcode should be fine.

I'll try UBL tonight

probably becasue JUNCTION_DEVIATION is default since 2.0.9.4

I also have JUNCTION_DEVIATION activated on 2.0.9.3

Here are the files from that version

confi 2.0.9.3.zip

Ok, it seems that ABL calculates or does something different after version 2.0.9.3

I did the following tests yesterday:

Version bugfix-2.1.x with ABL Bilinear (25 points) => failed
Version 2.0.9.3 with ABL Bilinear (25 points) => succeed
Version bugfix-2.1.x with ABL Bilinear (49 points) => failed
Version 2.0.9.3 with ABL Bilinear (25 points) => succeed
Version bugfix-2.1.x with UBL (100 points) => succeed
Version 2.0.9.3 with ABL Bilinear (25 points) => succeed
Version bugfix-2.1.x with UBL (100 points) => succeed

I'll be using UBL then. Thanks for the input!

Found the problem... after getting the same error again, even with UBL
By default I always increased the buffer size:
#define BLOCK_BUFFER_SIZE 64

Somewhere in another thread, about SKR boards, someone said to increase the slowndown, so I did:
#define SLOWDOWN_DIVISOR 16

After this my problem stopped.
JD works fine again, on UBL and ABL.

Maybe it is an idea to write a comment at "BLOCK_BUFFER_SIZE" to increase the slowdown if the buffer gets increased.
This is at the moment only commented at the slowdown

I have the same or similar problem (although on a SKR Mini E3 V1.2 ) but independent on Z height. On Marlin 2.0.9.1 there was no issue but after updating to 2.1.2.1 every print stutters at speeds above 50mm/s at every direction change. LCD also becomes very slow. The Config was manually matched to old one, so no new features should be enabled which could cause this.
Junction deviation is not the cause, it was also enabled in my 2.0.9.1 build. ABL and UBL not enabled/used.

Reading the previous comment, I tried the following in the config:
BLOCK_BUFFER_SIZE 64
SLOWDOWN_DIVISOR 16

Which did NOT solve the issue.

Anyway this is still a big issue, since 2.0.9.1 worked fine and suddenly the printer is useless.

Nice to see that someone else has a similar problem. I kept this issue open because it also didn't get fixed with me.
The settings
BLOCK_BUFFER_SIZE 64
SLOWDOWN_DIVISOR 16
did do a bit about the printing issue but it never went away...
The problem did only occur when I was printing 1) a very detailed piece with many rapid movements or 2) a big file +- 200mb

I tried everything (bug fix with ABL and UBL) but it kept happening. I have 2x Ender 3 Pro now.
1 stock with 4.2.2 board
1 with BigTreeTech SKR mini e3 DIP V1.0 with TMC2209

And I can say that the stock has only 10-15% of doing this stuttering (can't confirm the slow LCD response) compared to the other one. The stuttering also happens with any version after 2.0.9.3 on the stock one. The version 2.0.9.3 is the last stable one. No stuttering at all, fast printing and no LCD problem.

@radry , please try marlin 2.0.9.3 because this seems to me the last update that everything goes well. Maybe try the 2.0.9.4 after that and let me know the result.

I was having the same exact issue in 2.1.2.1 and switched to 2.0.9.3 and it fixed it

@MeloenBe
I give up. I tried 2.0.9.4 and even went back to 2.0.9.1 but I suddenly had the same issue in that version although never before. So I started to suspect the slicer because that's also an element that I updated at the same time. So I went back to Cura 4.12 (last known working version for me) from 5.6 but the issue persisted (maybe the new versions settings "poisoned" the old version? I have no idea if and how cura shares settings between versions). I even tried going back to classic jerk, just in case. I also reseted the eeprom every time, to be sure. I'm at a loss, no idea what happened. I ruled everything out that could be a potentional cause.

The choppy movements starts at the second fast layer, so the first ones goes fine then it seems the "command queue" is full and the board can't keep up processing or delivering the commands. What is strange is that changing the settings as mentioned in my previous comment didn't have any effect at all. Maybe as a last ditch effort I'll try a new SD card (not for the firmware but the print files), could be that it got corrupted and thus can't be read fast enough?

The bug started in 2.0.9.4 , so someone should check deeply in the code what changed with 2.0.9.3

It has to do something with the leveling part because after the fade height (10mm for me) is reached, the print goes fine.
The closer I get to the 10mm , the less the stuttering becomes.
As mentioned, it seems only to happen in the outer + inner layer but certainly not in the bottom/fill layers! These go fine.

@radry
Start from a clean version of 2.0.9.3 and format your SD card (slow format!)
I don't think the slicer is the problem. In my case I kept using the same sliced model on each version to test in which version the bug started.
Do you use ABL or UBL?