First, what is "divide and conquer".
Divide and conquer refers to a computing paradigm, which at once describes the way that many algorithms have been optimized and also the way that software has traditionally been structured. One wishes to break problems into small parts, because problems are more cleanly solved in this fashion. The small parts can be worked on and optimized separately and cleanly.
Enter bitcoin.
Bitcoin is:
1) A unit of currency
2) A payment network
Of course this list continues in various directions, depending on who you ask.
So you see already, there is a bit of a conflict here. How is this anything like divide-and-conquer computing? How can we clean this mess up? Well, it turns out it looks quite difficult to tease these functions apart, and not only because the whole thing is running as we speak. However, it is starting to become clear that the reason these functions are bundled is because a bootstrapping phase was needed.
For example, how could one have a currency without a payment network? One needs to be able to transfer an exchange commodity, that's why it is an "exchange" commodity. Right? Well yeah. However, gold, coins and paper monies do not have built in payment networks. One needs dwolla, hawala, and visa to fill those roles.
I'm just going to come right out and say it: TX relaying could be external. As Moshe Babaiof et al. said, there is in fact little incentive to relay TXs. As a coin collector and not a miner, I might want to keep a copy of the blockchain. I might not want to mess around with keeping a mempool full of dust and clog my bandwidth with copies of peoples laundry receipts. Is that so hard? I don't mind paying an external company or a pool operator to get my TX on a decent queue into a block. Heck, I pay a fee already.
One trouble with this is that reports of 0-confirmations go out of the window. Sure, one could get a 0-conf TX report from a pool or external relayer, but that isn't quite the same. Bitcoin retail point-of-sale without any chosen third party or zero-conf reports becomes difficult due to the relatively long wait between the blocks. But wait, does it? Why not - here's a wild solution - let the retailer deal with your TX? I mean, seriously.. here's a signed transaction for the amount I owe you. Isn't that just as good as a zero-conf copy of the TX from some random nodes? And I don't have to dick around with logging into the store wifi that way either. And isn't a bitcoin cheque (aka paper wallet) better than a bank cheque? The only difference is that you can deposit it yourself and check its validity online whenever you want to. The fact that merchants use credit cards shows that a payment processor and a longer wait to absolute confirmation is not a barrier to commerce.
Lets separate the problems please folks! Unit of account and payment network: two different issues. Blocks and TXs go down the same pipes today. That doesn't mean they always will.
Regardless of your opinion on ease-of-use or whatever, which bitcoin doesn't give a shit about, the way forward seems relatively clear. People will rely on bitcoin TX node relaying less and less, pools will make it easier to submit TXs to them externally, and other external networks will do more business. The blockchain and the mining software will slowly be separated from the TX relaying software. Phrases like "the mempool" will be replaced by "our mempool". The number of "full nodes of type XYZ", where XYZ refers to some stringent TX memory storage test or whatever will keep dropping. And blocks will keep coming in, only with more organized piles of higher fee TXs in them.
You might be tempted to say "oh this is centraliztion, you are suggesting a return to the old era!". Hogwash. First of all I am not suggesting a course of action, I am predicting. Secondly, the blockchain additions are decentralized, not the TX relaying. That the coin is public means it cannot be counterfeit: this much we don't lose with external TX relaying and is the whole fucking point really. Anyway, nobody wants to stop all external providers from adding their centralized services, that would be ludicrous.
Addendum:
Another way to look at the picture is to see bitcoind as a collection of small tools. A bitcoin kernel, if you will. This way we have room inside the daemon for a TX relayer, associated mempool maintainer, wallet database, associated TX signer and EC tools, block verifier, getwork manager, network manager, can opener, and cowbell. Heck lets throw in a vanity wallet generator, a copy of gpg, an aes alogorithm we found lying around, and 6 times the yeast for good measure. There is nothing wrong with building a nice kit like this, in fact they are quite useful. However one would be mistaken if one thought all this kit was a specification of the consensus protocol.
To be clear: we can rip the pieces out when we need to work on them, and then we can put them back in their cases.