Well, actually the result isn't reversed to original state.
Anyway it seems an expected behavior.

<?php

$data = "\0\t";

$esc = pg_escape_bytea($data);
$unesc = pg_unescape_bytea($esc);

var_dump($esc, $unesc);

?>

Output:

string(10) "\\000\\011"
string(8) "\000\011"


Nevertheless, says the documentation: 

  "This conversion is not exactly the inverse of PQescapeBytea, because the string is not expected to be "escaped" when received from PQgetvalue. In particular this means there is no need for string quoting considerations, and so no need for a PGconn parameter."

And about the two backslashes:

  "Certain byte values must be escaped (but all byte values can be escaped) when used as part of a bytea literal in an SQL statement. In general, to escape a byte, it is converted into the three digit octal number equal to the octet value, and preceded by usually two backslashes."

not a PHP issue, using the libpg API directly from C shows the same issue:

-------- pgtest.c -----------------
#include <stdlib.h>
#include <stdio.h>
#include <libpq-fe.h>

int main()
{
  unsigned char from[2] = "\0\t", *to, *to2;
  size_t from_len = 2, to_len, to2_len;

  to = PQescapeBytea(from, from_len, &to_len);
  to2 = PQunescapeBytea(to, &to2_len);

  printf("'%s' '%s' (%d)\n", to, to2, to2_len);

  return 0;
}

------- result ------------------
'\\000\\011' '\000\011' (8)

See also the last paragraph of the libpq PQunescapeBytea()
function documentation

"This conversion is *not* exactly the inverse of PQescapeBytea, because the string is not expected to be "escaped" when received from PQgetvalue. In particular this means there is no need for string quoting considerations, and so no need for a PGconn parameter."

( http://www.postgresql.org/docs/8.3/interactive/libpq-exec.html#AEN31707 )

.