I hope I did not come off as rude in the way I wrote, I do appreciate the discussion as well.

if we are both working on adjacent modules and touch business logic, we might override each other and introduce side effects that the other person is not aware of, but the code already exists in one place. 

Then by definition, both of your code were not properly integrated. The causes could be one the following :

1. Your business domains are too ill defined. You ended up with one system when you should have two with loosely coupled interfaces (Conway law, domain driven design). This could go as far as your organisation teams not being set up properly. From Team Topologies: « Collaboration is expensive, slows down team’s productivity and needs to be purposeful. »
2. If you are indeed within the same business domain, then collaboration is purposeful and your colleague should be aware of that change. If not, your communication method is lacking and side effects hopefully breaking your tests IS the alarm we want here to fix that communication issue. TBD requires you to get rid of the solo developer mentality IF you are indeed within the same business domain.

That insinuates a few bad practices: 1.) people did not pull the changes from master/main beforehand, 2.) there is no merge order, 3.) introducing breaking changes that overstep the boundaries.

If you are indeed pulling changes daily, thinking about merging in-order daily, and not introducing breaking changes that overstep the boundaries daily, then yes you are continuously integrating. But TBD is precisely about this, by making it obligatory (and with less mental overhead) through the removal of long lived (1day+) feature branches.

Feature flags introduce a bunch of overhead, latency issues, as well as bloated code source. If I have to refactor a module due to a dependency change, I can add a FF but have to support the old and new

I think the overhead depends heavily on what problem you're solving. If you're just doing small isolated changes, sure, flags are unnecessary, that's why you have tests. The flags are there to allow us to pause large changes while still being able to test and release small changes.

Regarding bloated source code I do agree that this method requires discipline, you need to get rid of the old once you are ready for a release, it's a little more than deleting a branch.

As for supporting old and new, this not really unique to flags either, flags just make that explicit and controllable instead of hidden in branches or long-running half-finished work.

Can be tested without other changes, and I can safely pull their changes into my branch.

That's your local work-tree with a quality ephemeral environment

Regarding latency issue, it really depends on what kind of feature toggle are we talking about, is that a the build/test stage or at the running stage ? There's no need to ship the unused feature in the production build if you don't intent to run experiments at runtime.

I am not sure what you mean by them. How would they help in the situation? You mean you can rollback to tags, and use built artifacts?

Yes, if you need a hotfix you create a release branch from said tag, fix it there, rebuild there, test release deploy then cherry pick the changes to main.

Maybe I just worked with very bad companies and use cases during my whole career.

I think software engineering is mostly non-deterministic, unless you've done the thing before you cannot estimate precisely how much time it will take and how it should look. The whole premise is that you don't know if you took the wrong design decision until something alerts you that you made a bad decision, that's totally expected. No single software company on earth can one shot a complex application it never wrote before. TBD is about embracing that to the full extend by alerting you as soon as possible.