Clearly an integer?
Likewise, when I write a piece of code that says x=x+14, It seems pretty clear that x is an integer.
There is an incredible amount of ambiguity in the expression x = x + 14. Yes, x may be an integer -- but is it signed or unsigned? And by integer, do you mean char, int, long, long long, int_64, etc.?
Or, perhaps, x is a floating point number. In that case, is it a float or a double? Are there any extended fp formats to deal with (with corresponding performance implications)?
Or might x actually be a pointer? I can certainly conceive of situations in which I might want to advance a pointer into a string by 14 characters. But I'd also like to know if that string is of normal or wide chars.
Of course, x might be an instance of a C++ class that has overloaded the + operator. If this is the case, I have no idea what in the world x = x + 14 means.
Without sufficient context, it is impossible to attribute any semantic meaning to an isolated expression or statement. The whole point of HN is to distribute that context throughout the code as much as possible, so that a programmer need spend a minimal amount of time searching for the context, as opposed using that time to actually understanding the logic of a given piece of code.
The contextual hints provided by HN are especially useful when browsing through unfamiliar code, when the intention is to get an overview of what the code is doing (as opposed to deeply examining a given segment). Such browsing is quite common in any large scale project, especially when one is tasked with debugging another's code (and you don't know where the problem lies) or modifying an existing system.
And finally, as another counter to the Torvalds "changing types requires much mucking through code altering variables' names" argument: how often does one blindly change a type that is pervasive throughout a system? Altering a structure used by many components of a system carries with it drastic costs -- at the very least, the compiler errors that will occur due to (for example) changing the name of the structure member will aid in the task of examining all uses of that member to ensure that they are consistent with the new type.
Of course, elements of HN can be misused, and a too strict adherency to a set of HN rules can cause more problems than they solve (e.g., UINT v. DWORD usage in Win32 code). But, as has been clearly pointer out, any coding standard can fall prey to this problem.