since there isn’t a polynomially bounded algorithm to find
xwherekeccak(x) = h(s). This is only true if the second hash function is a different hash function
Introducing a new hash function for preventing collisions adds extra complexity with no considerable gain in security. Also, sha256 has efficient ASICs developed, which can make it unsafe to use in this situation.
An alternate approach is hash offsetting. For burning ETH, one could send funds to the address r = keccak(secret) - 1. Later, they can prove that the address r is just an offset from the hash of the secret. For someone to spend funds sent at such an address, they have to find x and s such that keccak(x) = keccak(s) - 1. This is comparable to a collision attack. Hash offsetting is also seen in ERC-1967: Proxy Storage Slots to prevent hash collisions.
PoW and address space extension would help as the nominal 80 bit security is not enough, see EIP-684: Revert creation in case of collision and EIP-3607: Reject transactions from senders with deployed code.