Are you sure that your 64 bit chroot is configured properly? Can you run a shell within the chroot and execute ls? (Indeed, is there a shell in your chroot — exec() calls popen() internally, and that will return 127 if the shell can't be executed.)

We manage the servers with similar configuration through Chef so configuration should be the same.

Both 32 bit and 64 bit configurations have:
disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,

ls -la within chroot /path/to/chroot works. Other binaries work too, wget etc.
(/path/to/chroot is debootstrapped).

Also tried looking at php5-fpm -i but same output on 32/64 bit.

I have tried to upgrade PHP to 5.4.32, Debian to 7.6, and also the chroot'ed environment, but the problem still exists. I was hoping the problem would magically solve itself later, but this rarely happens :)

Disabling chroot in PHP FPM configuration does make things work as expected on 64 bit platform being able to run external binaries, this however is not a good option so we'll keep running 32 bit PHP instances with chroot configured for now.
  
Is it possible to have a paid review/debug session ?

In our environment I forgot to bind mount both lib and lib64 on 64 bit! (brain fart!)

mount -o bind /var/opt/chroot/lib /mnt/storage1/domain1/lib
mount -o bind /var/opt/chroot/lib64 /mnt/storage1/domain1/lib64

Now it works :D

Terrific; thanks!