Not sure I understand your question correctly, but I interpret your question as being about the rationale for the approval step in EIP20 and not really about EIP677. EIP677 is a workaround for providing the functionality in ERC223, without some of the issues of (non) compatibility with ERC223 -- "This ERC  aims to provide the helpful functionality of ERC223 without colliding with it.". Specifically ERC677 allows multiple steps to happen via one transaction+call loop thus avoiding the inefficiency of multiple calls.
On that basis, the following should help with understanding EIP20's approval step:
- The EIP20 Standard covers situations where an external account or contract account needs to be "authorized" (ie approved) to transfer your tokens up to the
_value amount. That's referred to as an "allowance".
- this is how NFT marketplaces, DEX etc are "approved" to transfer NFTs, crypto assets etc on behalf of the token owner when a sale/swap event happens. The Dex, or Marketplace contract needs to be approved to call the
transfer function in the token's parent contract and that needs to be done by the owner of the token or another address that's been approved. You can see some info regarding approve in ERC721 (NFT) contracts here in the OpenZeppelin Docs. While not exactly the same as ERC20 the intuition is close enough for understanding.
You can also see an example of how approve works by looking at the "Minting and Listing Three NFTs" section in this blog which explains the rationale. The owner of a token must approve the marketplace contract to notify the token's contract that the marketplace is authorized to transfer the token.
- Take a look at the OpenZeppelin implementation of ERC20's approve function here. The NatSpec comments will help you understand the role of approve as well.