There are two issues:
1. Type() returns incorrect values for instances of user-defined classes and exceptions.
2. The type system does not work as it should.
I stand by my assessment that it is incorrect to report a instance of a user-defined class or a exception as just "Object". Clearly either Chris or Lexicos has found it useful to differentiate between objects that are com objects, files, functions, and regular expressions. All are "objects" in the sense of a thing which contains state and has methods attached, but they have different semantics, and trying to use a function as a file will not work out well. There are other types that programmers want to use, and I don't believe it's desirable to have them operate on their data with a blindfold on.
I already gave one example (tree-walking) of where it helps to know the exact type of what you're dealing with.
Having a real boolean type allows you to do things like catch errors where you try to write a expression like 1 < x < 10 where x is 9001 which will silently evaluate to true in booleans-as-integers programming languages, and print booleans as booleans rather than integers. It is fine to allow converting between booleans and integers (useful when doing bitwise manipulation, like dealing with certain binary formats), but they should not be the same thing.
Having a real array type allows you to do things like check that an array (not something with string keys, for example) was passed to your procedure, and throw a exception with a meaningful error message if it was not, which might be useful when writing a library for public consumption, or an interpreter. I already gave a tree-walking example as well.
Having a real dictionary type mostly helps differentiate them from data structures that have array or object semantics. Again, I already gave the tree-walking example Using them well tends to require a set of facilities (e.g. the ability to list all the keys) that don't make sense when applied to arrays or instances of classes. When you "see" a dictionary it usually means the data within needs to be searched quickly, or indexed with something other than integers.
Differentiating behavior based on the type of a instance of a class is usually considered bad taste in dynamically typed programming languages, because it interferes with the benefits of polymorphism. However, those that want to write libraries for public consumption, or interpreters, or just generally want to assure the preconditions of a method are being obeyed, might enjoy being able to tell that they are working with a class of some sort, not a array or dictionary. "Calling" most dictionary's keys won't work, since values are unlikely to be functions.
I've seen all this type-punning before. Treating true and false as integers is widespread, unfortunately. Many modern statically type checked programming languages (e.g. ML, F#, Haskell, C#) and some dynamically type checked programming languages (e.g. Lisp from 1958, Python) have a separate type for them. Lua and JavaScript use dictionaries as arrays and objects. They are the only examples I'm aware of. Just because the AutoHotKey type system is as it is now does not mean that the laws of mathematics requires it to be so, or that it is the best of all possible designs. Since v2 is breaking compatibility to try to improve the programming language, it might be time to improve the type system.
It is, of course, possible, to work around all this. I can write my own Type() replacement that does something cute with static variables and memory addresses to recognize something Type() considers a "Object" as an exception, and failing that check to see if "__Class" is empty and if not report the type as that, and then enumerate all keys and if they are not part of the "generic set" on all objects assure they are all numeric without any gaps and if so report it as an array, and then there's dictionaries and so on... But this is all inefficient (very much so in the array-recognizing case). Or I could go OO-crazy and define my own types for everything and check "__Class" or the existence of certain custom methods everywhere... But this makes passing information to and from my code a pain due to the constant marshalling of data between AutoHotKey's basic types and my own personal Kingdom of Nouns. It all gives the appearance of plastering over cracks in a flawed design.
As to your criticism of my criticism of the inconsistent naming of the types returned by Type():
"Of what value would consistency be in this case?"
In my informed opinion it is inconsistency in design that must be defended, not consistency. So I ask you, what is the value of inconsistency in this case?
"Or more generally, of what value is the suffix?"
The value of the suffix is that it tells me it is a object, and thus has methods, unlike, for example, a integer. If AutoHotKey was a pure object-oriented programming language (e.g. like Smalltalk or Python), it would indeed not have any value.
I believed this forum was for constructive criticism of AutoHotKey v2. That's what this is.