It's hard to come up with examples where idempotency is impossible (I'm sure there are some)... but there are definitely cases where it is difficult. Counters are one of the most obvious examples; to make them idempotent you need to jump through a lot of hoops. Usually you assign a transaction-id to each increment/decrement operation and you keep a log of which have been applied. Suffice to say this explodes the cost of storing a counter (which would otherwise only require 32/64 bits).
Other things are hard to make idempotent but it's stil practical. Examples of this include operations like "delete all rows matching query Q". This either means "delete all rows for now and forevermore" or "delete all rows that exist at time T". In either case new rows matching Q might arrive in the future (but be antedated to the past) and you have to store the operation around in some way to apply the delete operation in the future. This can be easy if your query is easy to represent, and there is a limited class of such queries.
Sorry, it's hard to be precise about this in comments. The bottom line is Gizzard is not perfect for everything but idempotency is worth jumping through hoops a lot of the time (Gizzard or no!)