I also hate heated debates but just to comment on your reasons:

1: Blueprints literally show the node that is causing the error, usually "this isn't working because this is not a valid input" or whatever. Mabye for more complex cases they are harder to track down, but generally I've found that errors in BP take a few seconds to fix vs my previous experience in code searching through hundreds of lines to find I forgot a semicolon...

2: Merging is probably quite messy (I don't really ever do it since most things don't take too long append in (copy + paste all nodes from the BP you want to merge from and create the missing variables)- unless you have a huge list of functions on each BP then it wouldn't be tedious to do!

3: 10x slower may be true technically but it's not actually noticeable (especially not to the end user), unless you are planning on doing an insane amount of runtime computation with loads of giant blueprints. Plus in the next version there will be full converting BP to native C++ so you can do all the work in BP and then convert when you are ready to ship.

1. As for code logic, it's actually much easier to find your way, if you don't exactly know how you could achieve something, you can drag out of whatever node you are working with, put in some search words and a lot of the time you get the node with the functionality that you were looking for.

Honestly I think both methods are very viable for whatever the user wants to do, like many things, preference is what will make people choose one over the other. However, from someone who is more of a designer than a traditional coder, the visual system that ties so nicely in with the engine really feels like a step forward to a much more intuitive and accessible system that can really open things up to new developers.