Indeed, neither of the variables (niku_home / java_home) matter much for the XOG client, at least not in this case. It will set its own niku_home dynamically in the batch file anyway based upon the current location it is being executed from, so setting it up in advance would result in it being overridden.
The time you would want to take control of and set the java_home would be situations like having multiple JREs installed AND the one you want XOG to use is not the first one found on the path from a java -version. At which point the only thing it does, is that the xog.bat will prefix the current path with the java_home entry anyway, it makes no other difference at all.
I always have multiple JREs installed but I always explicitly have my path first pointing to the correct one I wish to use in each app, rather than setting/fiddling with the java_home which I have previously forgotten to reset when needed.
I strongly suspect the \AMD problem seen is just a similar entry in the PATH environment variable containing spaces and/or brackets which needs double-quoting. Note that you could have a situation where your path variable contains another variable, and that other one has the spaces/brackets, which isn't immediately visible when looking at the path statement alone under your computer properties > environment variables. In that situation I still double-quote the variable in the path statement to encapsulate it.
However I also only have and only use 64-bit JREs so there isn't anything 32-bit being invoked in my case - however if the installer of an application on Windows 64-bit platforms isn't explicitly installing a 64-bit application, then it (Windows) would simply choose the (x86) designated path as a preferred default program files install location. There isn't actually any additional impact it has on how the application is launched/run, except with respect to how Windows 32-bit applications may be subject to registry and path data virtualization (the virtual store behaviours) as a result of the SysWOW64 ("windows-on-windows") execution, but the path doesn't dictate that.
Although it is unfortunate that some versions of the XOG client result in it being easier to install and use it via the run.bat command I have also seen problems occur with this method that were not present when using xog.bat (no references of this to hand I'm afraid, I'm just recalling some past issues I've assisted with), and I would recommend resolving the path issues now one time until it is time to upgrade to a newer version of Clarity and use the xog.bat whenever possible. You'll note that the two have different entry points into the code (com.niku.xog.client.NikuGateway vs. com.niku.xog.client.XOGClient) and so won't be completely identical in their execution as clients.