That is perfect, and why this forum is so useful. I learn things every day here, and one of the things I've learned is to question my assumptions, because I'm often wrong.
One of my favorite replies to get is "Why don't you just do it like this...?", where the solution is so forehead-palmingly simple that it makes me, well, you know. 
That's exactly how I feel. Knowing that somewhere, there's someone ready to challenge my belief and show me a different perspective, because becoming better at something is always fascinating to me, even if my old beliefs need to be completely destroyed.
Haha I know exactly what you mean.
For example a few days ago I spent HOURS working on a macro to then share it here and I immediately got the "but you can do it with 2 lines of JXA" (or "there's already an app that does that"). So yeah, when that happens you feel like you waster a lot of time, but along the way I took so many notes and learned so many things, that it's never a waste of time. If anything, now I know that I don't have to spend so much time with something and should do some proper research first 
And if a single sub-macro is called by 50 different parents, it's 50 different complete macros you need to inspect to make sure there's no breaking changes.
Think of it this way -- there's two main types of sub-macro:
The first you'd use to break a big macro down into smaller macros, called in turn from a "controller" (I'm pretty sure you've got a couple like that). It would make sense to use Instance variables because the subs are specific to the parent, will only be used "within" an instance of it.
The second you'd use to enable the same functionality across a load of different macros -- that's your classic "black box", and you'd use parameters so that all those macros neither knew nor cared about the internals of the sub and, as long as you keep the required parameters and the format of any returned result the same, you can make any changes you want to the sub without having to keep checking/updating all those calling macros.
And, of course, there's no clear line dividing these two use-cases...
I get the feeling you're used to thinking of subs in the first context. So there's a whole other world out there for you to explore 
Up until today, in these 2+ years of using KM, I just had full macros and occasionally having "Execute a Macro" for specific things (either asynchronous or synchronous). I've never really broken down a big macro into small sections, if that's what you mean?
And I never really used Instance variables, because I didn't know how they worked until today. So for those rare occasions when I needed variables to be used, I just used global variables and if I didn't need them at the end of the macros that were running, I would just add %Delete%.
I know it's a convoluted approach, but I usually go with what I can do until I learn something new (which is what happened today by learning about instance variables, subroutines and the execute macro with parameter).
100%
I have a few macros (14 to be more exact) that are pretty much the same thing and when I want to update something, it's a pain!!! But at the time I just wanted to make them work no matter what. But now I can see how I will eventually convert them into subroutines and whatever I need to use from what I learned today
Let me explain one curious oddity/difference between the two that took me years to realize.
If Macro A calls Macro B "with Parameter C" and Macro B calls Macro D with no parameter, then %TriggerValue% will contain "C" in both Macro B and Macro D. But if Macro D calls Macro E with Parameter F, then Macro E will no longer be able to see parameter "C" but instead will see "F" as its own %TriggerValue%.
This behaviour means %TriggerValue% is equivalent to neither "Local" nor "Instance." If it was "Local," it wouldn't pass to submacros. but if it was "Instance," the same value would be visible in all sub macros.
You asked if they do the same thing. In light of this observation, no they do not do the same functional thing.
I always, and I mean always, setup an "Execute a Macro" action with "use parameter" checked, even if the parameter is blank. That solves the issue you mentioned.
I have a "favorite" action that has it setup that way, so I don't make that mistake.
And it's funny you should mention it, because I was just this morning thinking to myself "why do I do that?". LOL.
Great discussion here! Thanks for opening the thread @alltiagocom.
There are some subtle but important details with submacros and subroutines that I discussed in another thread: Avoiding Upgrade Issues with Submacros and Subroutines
The topic is a bit advanced, but if you plan share submacros and subroutines on the forum, I suggest you check it out.
I had no idea that worked. That's two things I've learned today. Thanks.
It's not really a big issue. It might even be useful in some cases. But it's unusual.
I just chimed in on that thread. You might want to check it out.
Nope.
Instance and Local variables are stored in memory in virtually the same way that parameters/TriggerValue are stored.
I would not even be thinking about it unless you are talking about multiple megabyte strings. And at that point, I'm not sure Keyboard Maestro would be the right tool for processing multi-megabyte strings anyway.