Did you try to compare rendertimes?

[tin2tin]

One of the Blender devs, LazyDodo, wrote to me: "if you render from the UI it'll generally do the color management in glsl which will appear single-threaded, when doing a CLI render, OpenGL is not used, and it'll run multithreaded on the cpu"

First I tried to render a 100 frames of a color strip, using Parallel Render, with just one instance and one part and it seemed to render as fast as the native Blender render(which actually used all 4 cores on my computer), spitting it into 4 instances and 8 parts seemed to render at least 10 sec. longer.

But maybe the speed enhancements are when rendering multiple tracks doing compositing?

[elmopl]

Short answer is "no". Especially not with newest Blender versions.

However, my parallel render was meant for very specific use case I had which was also the most common for me: rendering purely VSE project to h264 files. In that case all h264 compression was going done no CPU and that was bottleneck not being multithreaded. Nice perk was being able to render in chunks which meant when things crash I only lost ongoing segments.

If you're using it for rendering 3d scenes there might be no benefit at all.

And with all of that said, I haven't checked what happens on newest (2.83 I think at the time of writing) version. There might have been an enhancements to VSE/compression (built-in ffmpeg?) that would utilise all available cores. I haven't checked it.

[Zinput]

I tried the native Blender render compared to Parallel Render and Blender seems to use about 40-50% of all 8 threads of my CPU, and Parallel Render uses 100% of all threads.

[mikepan]

I am really glad I found this. Cut down my VSE render time from 27min with Blender to 2 min with 24 thread.