If the size of an integer is critical to the execution of your program, then you should be using int16 or one of the many other types that specify the number of (un)signed bits.
The int type is designed to be platform specific to optimize on execution speed when the maximum size of the integer isn't an issue.
And regarding optimization. Language-defined integer type size is one thing and CPU register sizes used in calculations is different thing. It's not like having 32-bit int forces you (or compiler) to use 32-bit registers.
For every int we (i.e. programmers) should be aware of possible min and max values that can be stored in it. Thus we can easily use fixed-size ints everywhere, paying attention to signedness too of course. The problem is that there is high temptation of using int most of the time, because it's easier to write (it's shorter). For the same reason many C programs use int instead of unsigned short or uint16_t for instance. Well-defined int size is part of self-documenting code, as it shows mindfully applied constraints.
My point is this: the problem when talking about "best practices" is there's some approaches that actually doesn't make a huge deal of practical difference, so it's more subject to specific circumstances (eg developer time constraints) or even just personal preferences (eg the arguments between ()\n{\n\t and (){\
Anyhow, in answer to your other post, the intn and uintn types have been available in Go since day one. So (and in answer to your original post as well), this int issue you raise isn't an issue unless developers have written extremely bad code to begin with (ie written counters which they know will exceed a 32bit integer and not cared enough to write an error handler nor specifically use an int64 type). Go does do a lot more to protect the developer from shooting his own foot off (more so than C/C++), but if we're completely honest, if the developer is crap then no amount of hand-holding from language design will help.
Actually, memory is even more of a luxury than ever, since your caches have limited size and main memory bandwidth is atrocious, compared to the speed of your execution units. Using 32 bit fields for stuff that safely fits into 16 bits can cost you for that reason alone.
I'm all for performance tuning and writing efficient code (like I said, I learn to program back in the 80s when every bit of data mattered and various tricks were used to work around the limited power of those systems), but let's be clear about one thing, memory these days is not "more of a luxury than ever". The exact opposite is true.