1. No, but I have yet to encounter a case where a "count" of something is anything other than an integer type of some sort. Redundant information is not useful
1. You haven't, that's just it. It could be a DWORD, long, even an [un]signed integer larger or smaller than 32-bits. Or it could even be a float or double. In that case, what if I just assume it's a standard 32-bit integer and try to do a bitwise operation on it?
2. The word "count" doesn't tell you much right off the bat, except what it's used for.
1. Why are you doing bitwise operations on a counter variable? A counter is something that counts. If you're going to do further operations on a counter then it has effectively ceased to be a counter and has become something else, in which case you should just create another variable or rename the old one with a name that better reflects what you're actually doing.
2. Which I am arguing is the most important thing about the variable in the first place. If I know what something is used for, most of the time what type it should be is self-evident.
I have found that it is far more informative to encode what a variable means as opposed to what it is.
Not really. Strings are kinda obvious yeah (not if you're cout-ing it though), but consider this: what if we have what is assumed to be an array or pointer? How can you tell whether it is a regular array vs a vector, or a naked pointer vs a smart pointer? There's so much you can tell about a variable by how it's named.
If I'm cout-ing, then I don't actually care what the type is, because cout handles that for me.
If it's an array, then the name will be in a plural form or otherwise indicate a collection ("apples", "appleCollection"). If it's a raw pointer I might put "Ptr" on the end, but only to distinguish it from other things in the same area of the code that are not pointers.
Most of the time I don't need to know if something is an array or a vector, they're both contiguous collections. And most coding styles I've worked recently with forbid raw arrays in favor of std::array or a similar collection.
Why do I need to know the difference between a naked pointer or a smart pointer when I'm just reading the code? When I read code, I'm usually trying to get a sense for what the code is trying to accomplish. If I need more than that, ctrl-F is very useful, and if I'm working on a particular section of code a lot I'll just remember what the variable types are because I'm spending so much time there. If I really, really need to encode the ownership semantics of a particular pointer variable in its name, then I'll probably choose to make it a bigger component of that name than a simple prefix at the beginning (which my brain could and probably would easily filter out, which I don't want).
Yes, there's a lot that you can tell about a variable by how it's named. Nobody is disputing that, in fact that seems to be the entire purpose of this tangent.
How does it make it look like "noise"? Is writing informative code a crime?
I have found that it's only informative if you've already learned Hungarian well enough not to have to think about it when you read it and are working with code that is so convoluted that following variable declarations is difficult. If you're writing code that others will read, then by using Hungarian of any sort you're forcing said others to give up room in their mental space for remembering what the prefixes mean and expend mental energy to parse them that could have gone toward actually understanding the code and solving its problems. If readers of your code don't do this, then it looks like noise (as in a random jumble of letters bolted to actually useful information) until they do. I'm not saying that writing informative code is a crime - far from it, I'm saying that Hungarian is not informative in a useful way and that there are better options, ones which impose less of a reading burden on programmers.
Also, I could live without many things code-wise, that doesn't automatically mean that I don't need it or shouldn't use it.
Paraphrasing a quote: "Programs (and other things) should be as simple and straightforward as they can be, but no more so." Hungarian notation, with its random-looking jumbles of letters, does not make programs more straightforward to anyone who isn't used to a style like that already. I have yet to hear a convincing argument as to why someone who hasn't already bought into systems Hungarian should start. If Hungarian works for you, fine, but for most of us, I doubt it would be worth picking up.
That is nothing short of asinine. It's a few extra letters in the form of a prefix, how *bad* can that possibly be?
Prefixes (and suffixes) themselves are fine. I use a number of them myself. I'm arguing that the way they're used in systems Hungarian is bad. A naming convention should be obvious to anyone who looks at the code, even if they are unfamiliar with the codebase, maybe even they're unfamiliar with the programming language itself. That means avoiding non-obvious acronyms and abbreviations (like "cs" for "critical section", "sz" for "null terminated string", and other Hungarian-isms) in favour of obvious ones (like "ptr" and "m_") and preferring to use full words where practical.
Plus reducing redundant information. Take the Hungarian "lpsz" as an example. This generally translates to a "const char *" in Win32 code. I would read that as "long pointer to a string with a zero on the end." Maybe that's useful, but "sz" already means the same thing, and is shorter. Given the syntactic rules, this is redundant, because a c-string is already a pointer (effectively). So a literal reading of this would actually lead me to believe that "lpszClassName" is a const char **, not a const char*! So Hungarian is contradicting itself here (or it's just a bad use of Hungarian, it's hard to tell really). Not only that, but "long pointer" itself is the same as "pointer" in anything more modern than Win16, so this is even worse - it's using a completely outdated naming convention that doesn't add any value. This among others is why I can't recommend the use of systems Hungarian in particular.
Lastly, virtually everything I code, do, believe, own, etc. annoys programmers and everyone else in general, so I could care less. I'm sorry, but nothing you are saying is convincing me that Hungarian notation is bad, and should be avoided.
To be fair, just about anything a programmer does will annoy some other programmer. 
(also, pet hate: it's could NOT care less)
