Except that no fork, to my knowledge, has implemented it in that way.  If it was algorithmically adjusted in the code, like the halving process is, you wouldn't need to hardfork every time you change the size of the blocks.  Every single fork out there in the market right now has a "magic number" (some of them just happen to be larger integers) and will need to fork again in future to change the cap on the size of blocks that are permitted.  It's effectively an endless necessity for hardforks.  That fits the criteria of "needless complexity" in my book.  The code for it might look simple, but the logistics are far more complex.  You have to get everyone to agree where the cap should be at any given moment in time.  As soon as people don't agree, your coin fractures into two and there's suddenly yet another fork for people to argue about which one is closer to Satoshi's vision.

In comparison, BTC is implementing things that should alleviate demand on the blockchain.  If Lightning can handle some of the load and other improvements can make transaction sizes smaller, this delays the need for any hardforks.  So far, that approach appears to be working.  I certainly hope that when the time does eventually come for a hardfork, we seriously consider an algorithmic method that would help negate the need for any future hardforks.  But, chances are, we're still a long way off having that discussion.

Lightning is more decentralised because you're giving users greater choice and self-determination by having the option of transacting off-chain if they choose to (or even atomic-swapping to another blockchain when that becomes more commonplace), rather than forcing all traffic down the same road with no other options and placing all of the resource burdens on the full nodes.  The market will decide how Lightning is going to grow and evolve, purely based on how people use it.  Unlike choosing a blocksize every time you start to approach full capacity, there's no central planning involved in how much or how little people choose to use Lightning.  

Ultimately, it's going to be a natural evolution based on the daily choices each user makes, rather than an evolution led by a group of developers picking an arbitrary number from thin-air and then seeing which developers people follow and which ones fracture into ever smaller groups, all solely fixated on their fixed integers.   

But fair enough if you think that's all too complex or it doesn't appeal to your preferences.  That's why the other forks exist.  Everyone gets to follow the route they think will work out best.