I've only been on medium-small teams, but I'll give it a shot:
Merging is essentially as banned as we can make it; we use Perforce, and set all .uasset files (Blueprints and other UE assets) as Exclusive Checkout so only one person can edit them at a time. This is recommended by Epic. When we do need to merge things, it's mostly a manual process of opening the Editor on two branches and duplicating all of the changes.
All of the refactoring-related questions, again, mostly manual effort. There are some constructs that can help keep things DRY which reduces the problem, like BP function and macro libraries. You also get inheritance and interfaces. UE also lets you redirect property, class, and function names to new names using "Core Redirects"; you can do that and then resave all packages to effect a bulk change.
Finding all references: Search All in UE will find a string anywhere; that means in property details, BP function calls, variable names, comments, anything. There's not exactly a "find references" as you might expect from a normal IDE though.
Really, the ultimate solution to dealing with these and the general "visual scripting spaghetti" problem if they're on the verge of becoming acute is to stop using Blueprint. We try not to use Blueprint for any complicated systems. It's nice for simple presentation-related things (e.g. "play x sound when y happens"), or places where we want designers to have some control for tuning or prototyping, but even for something that seems "straight-forward" like GUI code it can very easily end up spiraling out of control.
Blueprint also has a performance cost and it's hard to profile. UE5 dropped UE4's main attempt to fix this with "nativized" Blueprints, i.e. Blueprints that got compiled into C++. There are ways to improve Blueprint performance, but you really shouldn't even get yourself into a place where you're leaning on it so heavily that you can even worry about that.