R
There is a lot to unpack in your question, but from what I read I see two main issues:
the old guard (as you name it) doesn't want to change their way of working. What they did might have worked before, or not, but they found themselves a certain pace of doing things and the changes you want to bring forth are not to their liking. Since you mention a new guard, it means the team has grown, right? The old way of working might have worked with fewer people but now you need something else.
the second problem is I think you are in a company that's trying to be more Agile but not willing to make the necessary changes to achieve it. For example, you say that there is support from on high for some of the old guard arguments. And you as the team lead seem to be ignored? I am all for collaboration and listening out for everyone's ideas and input into matters, but as the team lead you have the last word. Apparently you do not have the authority also. And as an aside, and if you don't mind me saying this, your main pain point seems to be the merges and the conflicts, so why the heck are people "from on high" meddling into this? This is a pure technical issue for the team to resolve.
Now, to get back to the questions in the title:
Which is better large feature branches or merging frequently? Which is better small work items vs large work items?
The answer is small work items and frequent merges. This is not a preference of mine, it is something that has many advantages and is a subject for a few books on continuous integration/deployment/delivery or on why Agile advocates for incremental and iterative development.
You started your question by mentioning Kanban, but you then mention a Scrum Master, sprints, and you also tagged the question Scrum. In Kanban the idea is to have flow, to keep things moving. You keep things small, you use WIP limits, you build things, you deploy them. Rinse and repeat. This increases your throughput, and minimizes delays and dependencies. The longer you keep things around, the more delays you will have and the more dependencies will be kept alive while someone reviews stuff, or waits for other stuff to happen first.
One thing that make no sense whatsoever is why delay all work inside an epic. It's an all or nothing approach. If your epic has functionality ready then that should be released independent of the rest of things in the epic. The fact that you work on epics in a sprint is even more worrying and a sign that work decomposition isn't properly done. Items are to big to work on and get delayed as they all finish around the end of the sprint.
Another issue is this:
The work items hit code review and pile up and stay there for a long time. The following stage (the QA stage) is starved of work until suddenly everything is in QA and the testers have too much work instead of too little.
You do not have collaboration here. None. Stuff is being thrown over the fence to code review (CR) or to QA. Why is the CR delayed? Are people busy with something else or they don't like doing CR? Why is QA waiting until the end of the sprint with little work during the beginning of it? These are obvious signs of phase development within your sprint. Not good. Worse still, people are not swarming to unblock the CR and help QA. They've done their part, now it's someone else's problem. Again, not good.
The longer things stay un-merged, the more difficult it will be to integrate the work, and the bigger the chances of introducing bugs when fixing merging conflicts. If you are doing this at the end of the sprint then things are no longer fresh in people's minds and again a source of potential merging errors. When you do merges often, everything is fresh in people's minds and you have less surface for potential problems. And if something breaks there is again less code to search through to see what's going on, since the last merge probably caused it. When you wait for merges like it's some exceptional event that needs to be done only once, then people get incentivized to work as fast as possible to be the first person to merge, to then let everyone else deal with conflicts later on. It's a "not my problem anymore" mindset, which you don't want to have in a team.
Some things to consider:
identify as many issues as possible and discuss them at the retrospective;
find better ways to split the work. See INVEST.
find a process to handle the merges. I've used this one (slightly modified) without any issues whatsoever in a team with nine people.
realize that merging is not an exceptional event, it's part of everyone working together. Don't be scared of it (unless your source control tooling is bad - with Git for example that's easy to do)
add WIP limits to your columns and stick with them.
If something gets blocked focus your efforts on unblocking it before working on something else (even if you have not reached WIP limits).
try to gain the support of your Scrum Master and Manager on making the changes (you already have the new guard on board).
finally, lay out the new plan and ask for everyone's support in making it happen. Some will like it, some will not. Prepare to loose some people and even be prepared to let some others go. Don't go full on though at first, make the changes gradually. Start with splitting the work in smaller pieces and having some merge procedures in place to happen sooner rather than later, then try to increase collaboration with QA to minimize handovers.
As I mentioned in my comment above, you might not capture everything you need to do with just one question (my answer itself is all over the place because there is a lot of things that need to be done) so maybe ask further questions for clarification or ideas.
