Because you seem genuinely interested, I wrote you a paper (I haven’t proofread though).  If you read it like you will be tested, you will better understand my position.  In time, you might even agree.
(Bold is highlighting and All caps is inflection.)
I’m going to try to further “bridge the gap” in understanding, but I can promise you it won’t lead to a compromise on hard forks.  Not because my side is totally unwilling to compromise, but because we fundamentally believe that we cannot—literally cannot without severely harming Bitcoin.
Reasonable minds can definitely differ on how to interpret the actions and motives of Gavin and Hearn.  Again, I only have suspicions.  Implicit within your post (certainly inferred in my reading), however, is that you think my suspicions developed my technical perspective.  In actuality, it is my technical beliefs that most give rise to my suspicions about the two.
In reading your post, it would seem as though you think we have a technical disagreement over one matter: you think that Bitcoin is best of its block size can grow “organically,” while you think I think Bitcoin is best off if its block size is arbitrarily capped at 1MB.  I can understand why you see this as the primary technical disagreement.  After all, in arenas where the block size is most often “debated,” finding the “optimal” block size is typically the subject.
If that were our only disagreement, it would seem that we should be able to “bridge the gap,” and come to some compromise.  And because we have not done that, I can see why you guys might see our side as totally unreasonable.  But the truth is, before we could even get to debating the “optimal” block setting (including unlimited), we have to get through at least three fundamental beliefs that you guys don’t realize are truly fundamental.
(1)	We really believe that a contentious hard fork will split the chain and destroy value.
(2)	We really believe that all hard forks SHOULD be contentious, because we believe immutability is the most important property of Bitcoin.
(3)	Even if a hard fork were possible and safe, we really believe that the cost of running a node must remain low—low enough to operate over Tor with normal computers—in order to keep Bitcoin ungovernable.
(4)	Even if a hard fork with limit increase were possible and safe, we really believe implementing SegWit first and then deploying the Lightning Network is the best route.
Because most time is spent arguing about (4), which is most easily “bike shedded” and which would seem like a mere negotiable matter of preference, you guys might think we have just been unreasonably hard-trading for a year and a half, completely unwilling to compromise.  But the real reason there has been not compromise is because of (1)–(3), which you guys probably think we are only asserting as posture.  With regard to (1)–(3), Core developers and those who understand are not posturing—we truly believe it.  There are, however, quite a few cheerleaders/trolls for “our side” who probably also don’t realize how serious Core Developers are about (1)–(3), who probably think Core developers are just posturing; this probably becomes apparent in their arguments.  But make no mistake; beliefs (1)–(3) are held sincerely, and they don’t allow for us to “bridge the gap,” except through understanding—not compromise.

Each Belief explained:
(1) We really believe that a contentious hard fork will split the chain and destroy value.
Prior to Ethereum’s infamous fork that split the chain, we argued until blue in the face that if Bitcoin had a contentious hard fork, the result would be a chain split.  Peter Todd went on Bitcoin shows explaining that exchanges would be placed in legal limbo, because they would need to support both chains.  We understood that because of this, if Bitcoin split there will be a market for both chains.  We understand that the market for the original chain will not just suddenly switch from the chain that has garnered the market value (the one with the strong network effect and the first-mover advantage) to the forked chain.  Accordingly, any attempted fork will likely result in a split chain with both likely having less value than before the split (markets hate uncertainty).  All of the same people who argued that this would not happen immediately hit social media after the ETH fork to claim victory.  And then, after the old chain was practically dead, it was revived, and there was a market value for the original chain (now the original chain is longer than the forked).  All of ETH and most of the Bitcoin pro-forkers were truly shocked by this.  Those loudest (Brian Armstrong and Gavin Andresen) had egg on their face over the matter.  Ironically, these same people (mostly their followers) try to argue that it could not happen to Bitcoin because of the difficulty timing difference.
While there is some merit to the fact that difficulty changes things, a split chain can definitely happen to Bitcoin.  And those who said it would not happen have proven they cannot be trusted.  I would suspect that a Bitcoin chain splitting would actually be worse.  Because the ETH people did not truly believe that a fork was possible, the market mostly switched.  That likely will not happen with Bitcoin.  Too many of us know that a split is possible (at 75% hash or 95% hash), and we know that the market is not going to suddenly start valuing the forked chain, especially not after the ETH debacle.  But what a threatened fork will do is cause a lot of uncertainty and cause the market value to begin to decline even before a hard fork is executed.  Because of this, those who have the most invested in Bitcoin—miners, exchanges, and large holders—who could affect such a change will always be deterred from attempting a hard fork because of the prior market response.  They are also deterred by the post-fork uncertainty (practical certainty) of a chain split.  It was a bit of a mess for ETH, it would be a freaking nightmare for Bitcoin.
(2) We really believe that all hard forks SHOULD be contentious, because we believe immutability is the most important property of Bitcoin.
While you guys might look at the above and try to find a way to make hard forks possible.  We don’t see the value.  We think Bitcoin’s most important property is its immutability.  Accordingly, we think hard forks should always be contentious, because they are a threat to immutability.  I am part of the crowd of true believers that would extend that even to soft forks.  Hard forks remove rules, while soft forks add them.  I am glad to see that Bitcoin has progressed to the point where hard forks are practically impossible.  I want to see the political contention within Bitcoin factions grow to the point where even soft forks are impossible.  We may already be there.  While I think that SegWit is fantastic and am fine with its implementation.  But if it is blocked, Bitcoin will have reached another milestone towards achieving true immutability.  We don’t want to “bridge the gap,” because contention secures immutability.  This is, I think, the essence of so-called Nakamoto consensus.  As diversity in usership grows, consensus becomes impossible, and THIS is what ultimately secures Bitcoin.  Compromise and agreement are the enemy to immutability.
You guys will often argue that Bitcoin will be replaced by one that is “better,” if we don’t compromise.  But those seeking a secure store of value outside the purview of government don’t care about any other features if the coin lacks immutability.  The first-mover with true immutability will be hard—damn near impossible—to catch.  The market will move to Bitcoin and as it does, it will the market less and less likely to move to another.  There is a very strong network effect.  The only way we are presently willing to compromise is to delay immutability for soft forks like SegWit.  But make no mistake, that is a compromise—I will make more money faster if SegWit is "blocked"/"ignored"/"not voted for"/"whatever."  The market will value the benefit of true immutability more than any features added by SegWit.
(3) Even if a hard fork were possible and safe, we really believe that the cost of running a node must remain low—low enough to operate over Tor with normal computers—in order to keep Bitcoin ungovernable.
Until we overcome the above two beliefs, discussing this one serves little purpose.  But for the purpose of bridging the gap in understanding I am discussing.
Bitcoin has become controllable by far fewer people than intended.  Right now miners and exchanges could almost collusively force any change that they want.  But there is one check: ordinary users can run nodes that validate the blocks of even a few dissenting miners.  That is a BIG check.  That’s the check that kept the original Ethereum chain (ETC) running.  When the miners and the exchanges essentially colluded to perform a 51% attack on Ethereum, the original chain survived, because ordinary users could run nodes and validate the blocks of only a few miners.  This allowed the establishment of a market value, which lead to all exchanges having to pay people the ETH/ETC they deposited on the chain they deposited.  If this is not possible, the control of the protocol is left in the hands of a few.  And anything left in the hands of a few is governable.
We want Bitcoin to remain ungovernable.  Government governs at choke points.  If the cost of node operation increases to where ordinary users cannot participate, the government has a choke point.  In fact, the governments already has choke points with only a few thousand nodes.  But as long as nodes can be ran over Tor, governance is least likely.  Once ordinary users can no longer run nodes, they have no ability to resist changes (by running nodes and mining the original chain) they disagree with.
We want to see Bitcoin become less governable by decentralizing mining.  But increasing node cost beyond a certain point will result in a governable Bitcoin with no turning back.  When the Core developers looked at SegWit, they were not posturing when they said that the only downside was that it increased block size.  This is not viewed as a positive.  It is viewed as a move in the wrong direction.
Your preference to have an “organically” determined block size is diametrically opposed to our position.  Removing the cap Satoshi placed will result in removing nodes from individuals, and that is unacceptable to us.  We could accept the 1–4 MB SegWit allows, but that is pushing it.

Of course, once we start talking about this, this is where your side wants to start arguing.  That’s the pull of bike-shedding.  All of this is barely even worth discussing because of (1) and (2) above.
(4) Even if a hard fork with limit increase were possible and safe, we really believe implementing SegWit first and then deploying the Lightning Network is the best route.
There is probably most room to compromise here.  It seems clear to me that SegWit/Lightning first would be better, because then we could know how to change the block cap limit to fit the needs under Lightning, which will certainly be less than without.  But I guess it is “arguable.”  Regardless, because of (1)–(3), arguing about it is pretty much pointless.  We don’t like compromise, because we love immutability.  Our compromise on change has been to allow soft forks.  Our compromise on the block size is SegWit.  But eventually contention will block soft forks.  And if that happens now, then Great!  As it turns out, we did not have to compromise at all (although the benefits of SegWit are nice).