Canvas is rendered in the "RenderOverlay" call in he render pipeline. If we are talking about screen overlay the canvas is simply rendered in 2D space over anything previously rendered, which always happens last. I'm not entirely sure why this was in your question?
The advantage of Canvas is that it can render multiple sprites in one go, if and only if their states are the same. The batching technique is mostly useful if you're drawing lots of things to the screen. I'm assuming that each canvas is holding its own buffer for vertices ( I can't be too sure about it but as John Hamilton stated, it suggest to be the case ). I'm not entirely sure if 100-200 canvases will help you with performance Per se.
The mesh of the canvas is build dynamically by pushing vertex data to the buffer based on their screen coordinates, size and scaling, this is done cpu side which is then uploaded to the GPU, so there is a bit of work involved for your computer.
So ideally if you have a layout that doesn't change, you want to keep that in a separate canvas so that the buffer doesn't have to be rebuild and uploaded. Likewise if you have moving parts you want to keep those in a separate canvas as well.
Going back to your 100-200 canvases, I'm not really seeing the advantage here by giving your moving objects several canvases. If my assumption is correct about canvases managing their own buffers, you're creating a lot of them, and it is also safe to assume these buffers are created bigger to accommodate at least a couple of sprites. You're wasting memory and you're doing a lot more calls to the gpu to update the data.
It isn't clear if those canvases have static layouts or moving parts either.
You have to test some of this yourself. Use the Frame debugger ( or RenderDoc) to see what is going on when objects are rendered and what buffers are created.