[Sharparam]

One reason could be if you make something that you want to behave like a Frame's event/script system. Say you want custom callbacks for some object you have, like:

local object = {callbacks={}}
 
function object:SetScript(typ, func)
  if not self.callbacks[typ] then self.callbacks[typ] = {} end
  table.insert(self.callbacks[typ], func)
end
 
function object:Fire(typ, ...)
  if not self.callbacks[typ] then return end
  for _, f in pairs(self.callbacks[typ]) do f(...) end
end
 
object:SetScript("MyCustomTrigger", function() print("foo bar baz") end)
 
-- Some code that does stuff and triggers the callbacks
object:Fire("MyCustomTrigger")

Yes, there's CallbackHandler lib for this kind of stuff, but sometimes you just want to roll your own when you don't utilize near half the features of an existing library or don't like the particular way they implemented things.

Implementing the above on a Frame wouldn't really work while making sure there aren't any problems with the Frame's own SetScript and related types of events/triggers. Forwards compatibility can also be a concern, why put your addon at risk of being made incompatible with a future patch when it's preventable with little effort? Using different names would work, but why not choose a method that lets you use whatever name you feel fits best.

And if you're just blindly using a Frame to put all your methods in, you could be unknowingly replacing something that the Frame actually uses for whatever purpose if you don't check the documentation before implementing a method.

I like to have the comfort of knowing that whatever I'm putting in my tables, won't directly conflict with anything and lives in its own space. I do sometimes put things in Frames, but mostly for one-off objects. An example being in the options file of one of my addons (code is in MoonScript, but should be relatively readable I hope).