Why does the $PATH of an ssh remote command differ from that of an interactive shell?

From ssh(1) manual page: "If command is specified, it is executed on the remote host instead of a login shell."

So in short when you actually login to the machine bash is started as a login shell and loads the apropriate files, when you connect remotely and issue a command it is run in the place of bash, which means that these files do NOT load. You can work around it with using su -l -c or similar in the command part of ssh.

In some cases I've seen -t argument to ssh work (allocate tty) too.

Edit 1:
I think the PATH information you found, that the default path (unless we override it) is the one compiled into sshd. I made sure that my /etc/profile, /etc/bash*, local dotfiles, etc. didn't have any PATH information in it, then I logged on and still had a PATH. I searched for this one in sshd and found it there. So its how the manpage says:

ahnberg@remote$ strings /usr/sbin/sshd | grep -i x11 | grep bin
/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

Then I add PATH=$PATH:/my/test to the very top of my .bashrc file on remote, and check it again:

ahnberg@local$ ssh ahnberg@remote "env | grep PATH"
PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/my/test

So I can absolutely influence it, and default PATH is the one compiled into sshd. :)

I was able to get ssh to run commands using the remote path by running:

ssh dist@d6 "bash --login -c 'env'"

Here env can be replaced with what ever command you'd like.

I have authorized keys so didn't need a password to run the command or ssh.

I came up with a different solution to fix the problem. My personal preference is to create new configuration files instead of altering existing ones. This way I can easier destinquish changes from the default configuration.

Here are the contents of /etc/profile.d/ssh_login.sh:

#!/bin/sh
if [ "$SSH_CONNECTION" ]; then
    echo "User '$USER' logged in from '${SSH_CONNECTION%% *}'"
    . /etc/environment
fi

Using dropbear in place of openssh-server (this should also work with openssh), the SSH_CONNECTION variable gets set automatically when I log in remotely. I created a new shell profile configuration to detect SSH logins, display some information on the screen and, most importantly, load the global environment settings from /etc/environment to replace the compiled-in values. Please note that this only affects interactive SSH shells, not remote command execution.

Alternatively, if you use openssh and always want load the global environment, regardless of whether it is an interactive shell, you could place a symlink in ~/.ssh/ like this:

ln -s /etc/environment ~/.ssh/environment

Then you need to enable the PermitUserEnvironment option in /etc/sshd/sshd_config. Only do this for trusted users though, as this could enable them to bypass access restrictions in some configurations using mechanisms such as LD_PRELOAD. Please see man sshd_config for more information, specifically how to use Match blocks to constraint options to specific users/groups.

If you want the profile path to load, try:

#!/bin/bash -i

at the top of the script. That way the shell is in interactive mode when running the script.

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.

http://linux.die.net/man/1/bash