I don't see how it would work as a proof-of-work algorithm. Time-lock encryption is based on assuming that the owner of the data to time-lock is the one who knows the final secret and does all the computational work in parallel to get there. The time-lock is achieved by forcing the recipient to repeat a large amount of work in serial from a seed so there is no inherent aspect of this that benefits from being outsourced to a network of computers as a proof-of-work algorithm (it can't anyway, someone needs to know the secret.)
Something similar I worked on in the past is called a "timechain" (
http://roberts.pm/timechain.) Timechains are lists of time-lock encrypted ECDSA public keys that can be used in smart contracts to do refund protocols or to encrypt messages that are released automatically in the future. To ensure that messages are released, the timechain can offer incentives for breaking the links. This creates a race condition where the first person to break a link receives the reward. By claiming a reward, it simultaneously publishes the keys needed to decrypt all prior links in the chain, thereby providing an incentivized, time-released message service.
The problem with a timechain is that there is no way to know how fast the chain can be broken in the beginning when not enough people have gathered for the race (or people are breaking it in secret.) This means that timechains also need a way to halt the process with a federated system and random lottery for the next seed (to prevent attackers from racing too far ahead.) As more information becomes known about how fast the chain can be broken, trust can be reduced, and a person can adjust how far in the future they need to encrypt a message based on relative cracking speed.
Timechains require a trusted setup phase so they are only useful for a narrow range of problems. An idea that doesn't require the trusted setup phase is Greg Maxwell's sketch of an alt-coin based on time-lock encryption (
https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas see timelock encryption.) The idea is that an endless sequence of ECC public keys would be generated such that they were provably the result of some mathematical process (like pi.) Nodes in the network would then race to break keys for rewards in the chain. This has the same issue with my timechain idea which is that its impossible to know how far ahead in the future to encrypt a message based on some unknown cracking speed. Unfortunately, unlike a timechain -- solutions aren't known in advance so you can't artificially slow down the cracking. This solution therefore seems more suited to short-term time-lock encryption.
If you're interested, I have a few ideas for alt-coins based on brute forcing different functions to provide different services, as well as some small improvements to the timechain. I was going to publish them on my blog but I haven't had the chance yet.
