I would think most of us would be happy giving the capability to store longer strings in CHARACTERs and bigger numbers in INTEGERs without having to worry about it, I know I would.
It adds complications, more choices, headaches, subtleties and knowing where or what functions/statements support one data type or the other, at least without having to use the online help
Maybe LONGCHAR is more of an extreme comparison because of it's potential size, and maybe someone figured because of it's intended uses not to mention it's own set of challenges, limitations and so on, it truly is a different data type but is it the same case with INT64 ?
What is the reason for different integer data types ? Is it efficiency or storage size ? ABL strong points are simplicity and productivity, not writing intensive low level operations, and integers are variable size. Maybe it's more a question of what's practical to implement ? maybe there's a backwards compatibility argument that it'll break legacy code behavior (a startup parameter could possibly address such an issue) ?
If nothing else, it provides better mapping to other databases and languages which make this distinction. What would you do in a .NET interface, for example, which recognized both long and short integers if ABL had only the long one?
A secondary consideration is that suddenly bumping to INT64 everywhere might cause subtle bugs in places that were counting on INT32 values.
For INT32 and INT64, those exist in .NET because of OS/Machine/Server platforms (32-bit or 64-bit). .NET Framework does the mapping to the Int datatype for you. GUI for .NET is then mapped to .NET Framework's Int datatype. For the most part, you don't use Int32 or Int64 but rather use INTEGER.
As for the LONGCHAR and CHAR which are supposedly mapped to System.String, it is more problematic having both. I already encountered a DITEM error when passing System.String to a procedure ot method that has LONGCHAR as a parameter.