Let's start by saying that you are right, it is quite weird because the "init bytecode" is basically the deployed contract. With that being said, the yellow paper may have amends by the EIPs as it says in Understanding The Yellow Paper
The Yellow Paper is the formal specification for Ethereum. Except where amended by the EIP process.
You can read the Ethereum EIPs which their goal is:
To document standardized protocols for Ethereum clients and applications and to document them in a high-quality and implementable way.
Basically it's the rules of the protocol. The rules are necessary to provide working protocol without bugs or shutdowns.
There we can find EIP-170 that limits the contract's size, it also explains the rational behind this decision:
Currently, there remains one slight quadratic vulnerability in Ethereum: when a contract is called, even though the call takes a constant amount of gas, the call can trigger O(n) cost in terms of reading the code from disk, preprocessing the code for VM execution, and also adding O(n) data to the Merkle proof for the block's proof-of-validity. At current gas levels, this is acceptable even if suboptimal. At the higher gas levels that could be triggered in the future, possibly very soon due to dynamic gas limit rules, this would become a greater concern—not nearly as serious as recent denial of service attacks, but still inconvenient especially for future light clients verifying proofs of validity or invalidity. The solution is to put a hard cap on the size of an object that can be saved to the blockchain, and do so non-disruptively by setting the cap at a value slightly higher than what is feasible with current gas limits.