The short answer to if big dev house use blueprints for gameplay stuff is that yes they do.
There is the problem of diffing blueprint check-ins, however you can do historical diffs of blueprints in editor to view changes and try to spot any potential errors that a submit may have caused. Additionally, there is Data-Only BP Merging on the UE roadmap which could be useful, but doesn’t fully solve the problem: https://portal.productboard.com/epicgames/1-unreal-engine-public-roadmap/c/1282-data-only-bp-merging.
The primary use case for Blueprints is fast iteration that is super useful for prototyping mechanics and features that would then either be thrown away and re-written in C++ during production or it can be moved to C++ piece by piece, or refactored to be more performant through code. Since Blueprints are more accessible, non-technical people can be involved in the prototyping process and allow coders to focus on more framework related topics that these prototypes could then be injected into. Whether or not most logic remains in Blueprints is really up to how they are maintained and the requirements of the project.
One of the biggest weaknesses with Blueprints that I have experienced is the lack of ‘Blueprint Reviews’ that can help reduce bad practices and bugs; but these type of reviews aren’t very common. Code Reviews are more of an industry standard and its hard to move that practice to Blueprints simply due to the quick & dirty approach that they offer.
Outriders and Outriders: Worldslayer shipped with some of the gameplay handled in Blueprints, mostly abilities and complicated perks/bonuses that required logic. All-in-all, the overall structure of the gameplay, its framework, was in code, and then the individual abilities were done in Blueprint; with exceptions to either complex logic that needed to be done in C++ for performance or if logic could be shared between abilities.