Anti-spamming hash-based proof-of-work? I'm planning to implement a public mailbox for receiving feedback, and I'd like to use hash-based proof-of-work to frustrate spammers. 

First, we want to use 320-bit capacity Gimli permutation as the underlaying primitive for the sponge-based hash function, because 


I don't want to make it hard for server to re-evaluate KDF each time there's a message, 
it's not available on commodity hardware, which means someone will have to pay for silicon to have it accelerated, 
less parameters to tune (capacity/rate and preimage length). 


Second, for each message, there will be a time-based challenge (server will allow a small window for error) prepended to each message to be hashed and sent to deter pre-computation attacks. 

However, there's a few things I'm not confident about. Namely: 


Whats the advantages and disadvantages of using plain hash and KDFs when used in POW? 
Besides replay, pre-computation, what are the other attacks that must be considered in designing a secure proof-of-work system?
I agree with e-sushi that PoW does work, however, the primitives used by HashCash are too friendly for adversaries. As the OP pointed out we need contextually bound challenge and response that cannot be reused or precomputed.

We cannot prevent the work from being delegated; but we can make the PoW much more expensive than an ASIC friendly hash function. The argon2 KDF family is well suited for this, specifically argon2d which was designed for PoW; whereas argon2i was designed for secret passwords.

The memory and cpu parameters may be tuned individually such that no real users are too inconvenienced and the server is not overwhelmed when under load.

Instead of requiring the PoW be computed 100% of the time, you might only require it while the server is under load. This may not apply to your use case.


  
  Whats the advantages and disadvantages of using plain hash and KDFs when used in POW?
  


Advantages:


Increase adversary costs


Disadvantages:


Inconvenience users (less than a captcha)
More code running on the user's client, inconveniencing users who opt to disable JavaScript
Drain the power of user's mobile devices
Adds additional computational costs, increasing power consumption for minimal benefit



  
  Besides replay, pre-computation, what are the other attacks that must be considered in designing a secure proof-of-work system?
  



Remote delegation to unsuspecting users (like recently cryptominers on government sites)
Deniable of service. The adversary may produce fake solutions without trying. The server still performs the computational costs.


Alternatives:


Enable the user to send money as a micropayment. This scale will require a high performance ledger, or better many ledgers. On the other hand, an adversary may have enough money to burn, possibly stolen.