I suppose some tokens might not want to revert, but rather communicate to the caller that the intended process did not happen. This wouldn't change how contracts like swaps work, since Uniswap and others treat revert and return value of false the same, but some token consuming contracts may not treat them the same and for some token that does actually return false without reverting, maybe a consuming contract for that token wants to deal with that situation. So I think yes it is redundant for all uses of tokens that I've seen so far but I suppose there could be a scenario where it would be useful. If the IERC20 standard were up to me, I would have not specified any return type since the returns (bool) adds 200 more gas to the function. It also forces any consuming contract of an IERC20 to have to check the value, costing more gas. If it were commonly useful, I could see keeping it in the standard, but I don't know of any token that returns false, so I don't think it is useful at all. And we have things like Uniswap's TransferHelper.sol where: function safeTransfer(
address token,
address to,
uint256 value
) internal {
// bytes4(keccak256(bytes('transfer(address,uint256)')));
(bool success, bytes memory data) = token.call(abi.encodeWithSelector(0xa9059cbb, to, value));
require(
success && (data.length == 0 || abi.decode(data, (bool))),
'TransferHelper::safeTransfer: transfer failed'
);
} We can see that the contract has to do more work here since there is a return value.