While this is a bit subjective, there are good reasons for using a GUID or other value that is not coupled to the name of a plugin.

You allude to the fact that there are several global properties to a plugin:

1. A label, which is user presentation. This does not change the identity of the plugin and may change, for example, due to internationalization.
2. Plugins must also have a class or function that loads it and makes it “go.” This is a source code identifier.
3. Plugins should have a static ID such as a name or GUID. This is what you are asking about.

Clearly, the first two identifiers are not optimal. One is user-facing and mutable, the second has specific implementation problems (e.g. C++ name mangling). However, in languages such as Java and C# with pervasive namespacing through packages that is mitigated somewhat, but still less than ideal.

The third option is clearly superior. If a plugin or class name changes, the plugin is still identified as installed and needing to load. Preferences are still linked.

Why go with a GUID over an arbitrary name? A name may have trademark or copyright implications that force the author to change it. Perhaps a plugin’s scope changes, making the name inaccurate. Maybe the name translates to something taboo in a foreign language. There are plenty of reasons.

GUIDs get around these issues. Practical limitations aside, they are pretty much guaranteed to be unique, are not real words in any human language, and should never need to change.

As to why any particular software program uses whatever method they use to identify plugins, you need to contact the program’s authors. If I were writing a software that implements a plugin framework today, I would use GUIDs.

Why don’t we use GUIDs for our programming languages?

f0dbb9b8582c474ea899d4f66bf76040("hello world!")

… or this:

import f0dbb9b8582c474ea899d4f66bf76040 as console_output
console_output("hello world!")

That would allow the authors to change their mind all they want about the user-friendly label associated to the GUID instead of using a name like print which might clash with something else or they might later prefer to call console_out. They can still document f0dbb9b8582c474ea899d4f66bf76040 as a “print” function, later change their mind and call it whatever they want in the documentation, still associate a user-friendly name in the IDE when you hover over the code. All we have to do in response is make sure all the code we write uses f0dbb9b8582c474ea899d4f66bf76040 or an alias we give it very locally in our code which then allows the libraries to associate any user-friendly name they want and keep changing their minds without breaking our code.

And hopefully you see the very immediate problem there, though I actually had to explain this to my team of VFX professionals a hundred times or so and repeatedly across meetings and the topic just kept coming up each year, so maybe I’m really bad at explaining this!

Programmer Identifiers, Not Just User-Friendly Labels

It’s like you commit to a name and that name cannot be changed. I am
not an expert in designing these systems but wouldn’t it be better to
use some other info like a GUID for every plugin to create this link
between which plugins are being used in a file?

Plugins for software like Maya are not strictly providing features for users. They’re providing functionality for programmers. The exact same reason we might not want to use GUIDs to name our functions above is the exact same reason why all these packages avoid GUIDs for class names, command names, etc. They’re meant to be programmer-friendly identifiers directly referenced in code. The names are referred to in MEL scripts, Python, in other plugins, to alleviate the burden of the scripters and other programmers from having to refer to that thing via something as cumbersome and hard to read as a GUID.

So GUIDs are great if you just want to preserve uniqueness, but if you want to write code (ex: MEL scripts) and things like that which refer to an identifier, it’d be a real PITA to refer to things by GUID. So the practical alternative there if you want to refer to names in the first place already without exposing these GUIDs to scripters requires that the plugins register unique, relatively programmer/scripter-friendly identifiers.

So just like when we introduce new functions or classes into a codebase, we have to be careful how we name them, especially before they start racking up many dependencies. And GUIDs don’t help here when our goal is to create meaningful identifiers for our classes and functions so that other programmers can use them. GUIDs would just obfuscate everything for everyone. But you can kinda use GUIDs if you want if you take out the dashes (could be confused for subtraction operator) and make sure the identifier starts with a letter, or simply jam the keyboard like udshvuidhsfauishfdsihuxczv and name your functions and classes that way to ensure a fairly good probability of uniqueness if uniqueness is more important than the readability of the code.

I just thought GUIDs would allow you to basically bind the type/class
of a specific plugin to its instances used in files without the issue
of collision with other plugins.

They do and if all you needed was to register something that few things refer to while you add a nice user-friendly, localized GUI label on top, then GUIDs make a lot of sense. But they don’t make so much sense to use for programming identifiers (at least it would be quite a burden on the programmer to deal with GUIDs in their daily code just so that the author of the function or class is given more leeway to change his mind about the name of the class or function), and in Maya those names are just that: programming identifiers. Those new nodes aren’t just features but also things that can be invoked via script.

Maya is kind of like a visual development environment. The plugins aren’t just adding end-user features but new functionality which other developers can use/call/execute/invoke by name (identifier) to build more functionality. If Maya wasn’t that kind of uber-scriptable and programmable environment, probably GUIDs would make a lot of sense. And ZBrush is an example of a software that I believe uses GUIDs or something similar (saw these big IDs associated with UI elements when they offered debugging features for scripters), but ZBrush is more purely artist-oriented so it doesn’t bother with a plugin architecture (just ZScript which is very simple scripting). Maya is very TD and scripter-oriented. But given the way it is, those node class names are identifiers for other programmers to refer to by name.

GUIDs for Namespaces?

The idea of replacing the analogical namespace with GUIDs is interesting, like f0dbb9b8582c474ea899d4f66bf76040 instead of namespace std in C++. Maybe that wouldn’t be too cumbersome if we used using declarations and directives liberally to import everything. The problem however with VFX software is that many plugins often just register a command or two, e.g. They don’t necessarily add a whole bundle of functions to the software and very often just add one. So we’d end up having to deal with a boatload of GUIDs and quite often would have to copy/paste a new one (at least I assume most of us mortals would have to copy and paste, since I could never memorize a single GUID let alone hundreds) just to use one new function.