In my experience, bugs triggered on one architecture have a high chance of being present but silently hidden on other architectures, and thus keeping a program running on widly different architectures is a net gain for both code quality and robustness of a program. So I tend to be liberal with which architectures to list in the Architecture field in d/control, and only limit it if the alternative is not sustainable.
I also try to ensure the build will test the generated binary before calling the build a success, to reduce the risk of broken binaries making it into the archive. There is no advantage from a release critical bug in a architecture where no-one can use the package anyway, keeping the package out of the next stable release in Debian. -- Happy hacking Petter Reinholdtsen
