Perhaps it would make sense to make these unsafe calls as well,  but the justification I used at the time was that the amount of time consumed by these functions is bounded by the length of the string being escaped,  which is itself unbounded.    Certainly postgresql-libpq is currently overly biased towards safe calls;  though when I took the bindings over it was overly biased towards unsafe calls.   (Though, arguably,  it's worse to err on the side of making ffi calls unsafe.)

I've also considered integrating calls to c_PQescapeStringConn with blaze-builder and/or bytestring-builder,  which could help a fair bit,  but would also introduce dependencies on the internals of these libraries when currently there is none.

There is certainly a lot of room for optimizing query generation in postgresql-simple,  this I've been well aware of since the beginning.   And it probably would be worthwhile to move to protocol-level parameters which would avoid the need for escaping value parameters altogether,  and open up the possibility of binary formats as well, which would be a huge performance improvement for things like numerical values and timestamps.    Although IIRC,  one downside is that this prevents multiple DML commands from being issued in a single request,  which would subtly change the interface postgresql-simple exports.  

Best,
Leon