You shouldn't rely on this fact anyhow. You need to have the right abstraction layer (e.g. communication over IP is a good starting point). This is in part necessary to allow for "in service upgrades" i.e. adding newer machines that may/or not be of the same architecture as the starting cluster configuration.
Imagine going to your boss: "Well, we need to take to whole service down because we've got these fancy new machines ...". ( and I can hear the reply loud and clear )
Of course, if the concerns of a production environment is out-of-scope in your specific case, you can disregard my quote. Let's just say it would be a typical requirement for any big deployment.
Lastly, it is always easier to deal with a symmetrical cluster (maintenance is simplified) but then again, an asymmetrical cluster can be a "stepping stone" when dealing with a "rolling upgrade".
Clarification: I never eluded to abstracting everything away.
Clarification #2: by "architecture" I am assuming "CPU architecture" i.e. not "architecture of the overall system".
As for the second part of your question: it all depends on the architecture of your software.