Good questions! I can only speak of the current implementation, since there is an on-going work to change how update call is executed (Deterministic Time Slicing).
First of all, update calls addressing the same canister is only executed sequentially. So there is no parallelism there. They are executed one by one.
Secondly, there is (or should be) a limit to every aspect of execution, in order to prevent DoS attacks. Messages that are not immediately executed will be queued, and there is a size limit to the queue, so messages may end up being rejected if the queue is full. Messages that are already accepted by consensus may eventually be rejected at the execution layer, e.g., insufficient cycle balance, or execution running over block cycle limit, or the canister has been stopped, etc. Update calls are also subject to message size limit, about 2MB, which applies to both ingress (sent from user) and inter-canister (both xnet and on the same subnet).
It sounds like you have more than one target canisters here. Then yes, different canisters may process their own message queues independent of each other. So method 1 and 2 are “almost” equivalent. However, in practice, if the canisters you want to call are all in the same subnet, then there is also a block size limit (1000 msgs/block and 4MB total size) & block execution time limit (7 billlion cycles) that you need to consider. Inter-canister messages on the same subnet may be executed much more efficiently than those going across subnets, but then you will likely hit those subnet limits if you have a lot of messages.
Spread your canisters across multiple subnet is the only way to scale out beyond a single subnet’s capacity. Whether it makes sense to do that depends on whether your canisters need to frequently communicate with each other (because not all calls can be equivalently done from the user frontend). If not, then I’d say Method 2 + multiple subnet is a better choice with more parallelism.
BTW, the actually numbers of the above mentioned limits are subject to change too. They all have a default value in the IC source code, but their values can be adjusted through proposals, and may vary from one subnet to another. I can only speak from my best knowledge. You can use a tool called ic-admin to check for yourself (ic-admin --nns-url https://ic0.app get-subnet <subnet-id>).