Slowness of extended protocol

Hi all. I know this has been discussed before, I'd like to know what's the
current position on this.

Comparing the performance of the simple vs. extended protocols with pgbench
yields some extreme results:

$ ./pgbench -T 10 -S -M simple -f /tmp/pgbench.sql pgbench
tps = 14739.803253 (excluding connections establishing)

$ ./pgbench -T 10 -S -M extended -f /tmp/pgbench.sql pgbench
tps = 11407.012679 (excluding connections establishing)

(pgbench.sql contains a minimal SELECT 1, I'm running against localhost)

I was aware that there's some overhead associated with the extended
protocol, but not that it was a 30% difference... My question is whether
there are good reasons why this should be so, or rather that this simply
hasn't been optimized yet. If it's the latter, are there plans to do so?

To give some context, I maintain Npgsql, the open-source .NET driver for
PostgreSQL. Since recent version Npgsql uses the extended protocol almost
exclusively, mainly because it does binary data rather than text. Even if
that weren't the case, imposing such a performance penalty on extended-only
features (parameters, prepared statements) seems problematic.

I'm aware that testing against localhost inflates the performance issue -
taking into account the latency of a remote server, the simple/extended
difference would be much less significant. But the issue still seems to be
relevant.