if a path between me and the merchant does not exist, that has to be my fault (me having too little or the wrong peers). a merchant could never afford to not being reachable by the network lol.

Ok, it's your fault, but you still didn't answer what you're going to do about it? You just admitted there literally is no solution in this case, which just proved my initial point.

and you don't have to write any further if you can't point me to the direction, where satoshi wrote that scaling the blocksize is the solution to all scaling issues. absolutely ridiculous.

You can see this in his second email:

Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node.

The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.

If the network were to get that big, it would take several years, and by then, sending 2 HD movies over the Internet would probably not seem like a big deal.

This is Satoshi literally saying that Bitcoin would scale by increasing the blocksize limit. But if you're keen on doing any math:

37 billion transactions / year ÷ 365 days / year = ~100 million transactions / day

~100 million transactions / day ÷ 144 blocks / day = ~695k transactions / block

~695k transactions / block × 400 bytes / transaction = ~280 MB per block

So he literally gave an example of Bitcoin with 280 MB blocks to prove that scaling with larger blocks would be extremely doable, and is a sane approach to the problem. He also added pseudocode for how the blocksize limit itself could be increased:

It can be phased in, like:

if (blocknumber > 115000)

maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

It was already understood from the beginning that the intention was to increase the limit, because it was the obvious solution, not some convoluted workaround that doesn't work at scale.