Don’t use Godot 4.x for 2D gaming! 
(At least on the Physics Engine Side).
Here you can see 2D benchmarks executed with Godot 3 and Godot 4 on Desktop and Android Devices.
Godot 3.x is definitely better for 2D physics!
You can found HERE the test projects used (the Godot 3 and 4 versions).
This isn’t a good rendering benchmark, because you’re essentially benchmarking the physics. Godot’s 2D physics is crap regardless. If you need 2D physics performance, use the Box2D plugin.
Could you provide a bit more information about how you conducted the tests?
I agree with @award that this is more of a physics benchmark rather than a cohesive benchmark of the engine itself.
Additionally, my results seem to be the opposite of yours. In 4.2.1, I was able to maintain decent FPS through the test, but in 3.5.3, FPS dropped to single digits.
Its worth noting I tested on a laptop device with an intel integrated GPU.
I tested on Xiaomi Redmi 12 and Ubuntu 22.04 with Nvidia 750 Ti and AMD Ryzen 5, on both same results.
But have you tried pooling objects? 
In all seriousness, though, on my machine (base M1 MacBook Pro), I get identical performance (within 1%), around 300 fps on the low end.
ps: 489KB for png of a tiny-tiny ball is quite a lot. It can be a problem for machines with little VRAM (2000 balls = 1GB vram).
The title of your post is very misleading, change it if you can. From your title it seems as if godot 3.x is better for 2D in all cases, while here you are only comparing the 2d physics.
Firstly, if you are interested in raw performance, even without changing the physics server and godot version (3 or 4), you might want to look into the number of iterations the physics server does and the physics ticks per second. Ideally if you run a simulation with these many bodies, you want a lower physics ticks per second and to do some kind of smoothing on the bodies position.
Then, if you want you can replace the physics server (in 4.x only) and get a much better performance. There are currently 2 addons, rapier and box2d. Rapier supports simd optimisation, while box2d v.2.4 doesnt(v.3.0 is in work). Without parallel threads I got with rapier 5-6k circles for eg. In box2d v3 with parallel threads I got about 13k circles.
Here is a comparison I wrote of the 3(box2d, rapier and Godot Physics):
One thing to note, godot physics is really bad in terms of stability. If you have many balls stacked on top of each other of boxes, it will start to jitter a lot and objects will randomly teleport.
This is cool, thanks for posting!
Just the same resizing it to 11Kb 
Just changed the title!
Just done! 
Even with the new title, some people say that Godot 3 and Godot 4 are not so different in terms of physics. If people google this they might think Godot 3 physics is faster than Godot 4 physics, but that might only be true on 1 platform. If you want to make such a statement, you have to test in release for all platforms(eg android,ios,mac,windows,linux,web) only then you can say such a thing with certainty. Otherwise, people might chose Godot 3 thinking Godot 4 is worse for physics. And according to other people’s comments, some people got better results in Godot 4 for eg.
First if you want to do such tests, I would say to make sure you are running in release mode, and to state what platform and your computer configuration, and also put that in the title if you only tested on that.
It might not seem like much to you, but there are people who worked on this and this makes their work seem bad, while it might be an edge case on a system, or who knows.
I executed all tests in Exported/Release mode, always.
Anyway I understand and I wont ask to excuse me, I REALLY appreciate all the Godot Devs works, I just wanted to point out something that seemed to me to be a regression that needed attention, but I understand that it is an extreme case, I will change the title and thanks again.
PS: I cannot re-edit the title, if you can do it please.
Hey sorry for straying from the main point of the topic but wanted to highlight that this is not how VRAM works. The PNG file size is just that - the size of the file on the HDD. Upon import, it will be decompressed to a format preferable for the GPU, e.g. RGBA8 - for the ball this will be 1660x1665x4 bytes, which is a bit more than 10 megabytes. This may or may not be compressed on the GPU ( for example with S3TC ).
Additionally, even if the ball is reused thousands of times, it won’t allocate new VRAM for every single ball, as it there’s no need to. So it caps out at 10 megs of VRAM. Which is not a lot these days.
