Thanks for the proposal!
How about the destination L2/sidechains which support another address notations? Should be _to is bytes32 at least in this case assuming that in the worst case it contains keccak256 of a recipient address located in _data?
I agree with @Dzack23 that finalizeInboundTransfer must accept the additional bytes param. BTW may you also share more details (since the reference implementation you mentioned is not available by the link) what is _from and _data returned by this method, where did they come from?
Since you assume that pure ERC20 tokens can be locked on the gateway, I agree that the transferAndCall functionality cannot be utilized. So, probably it make sense to introduce a special method on the side which could be the tokens recipient like onTokensBridged(address _tokenContract, bytes32 _from, uint256 _value, bytes _data), doesn’t it? This method will be called from the contract-recipient by the gateway after unlocking/minting the tokens.
Another suggestion could be to consider a method in the standard to support a batching transfer. It could be useful for the cases when several users delegate transfers of different tokens from L2/sidechain to a service to reduce impact of L1-L2/sidechain interactions specific (like timelocks, gas prices etc).