Have you ever looked at a big long package/procedure and wondered what the scope of a variable might be in this web of nested named and unnamed PL/SQL blocks? I’m sure all of you have.
There are a few naming convention proposals out there that suggest using prefixes like “l_” for local, “g_” for global variables, etc which is some kind of Systems Hungarian notation (I’m not convinced of the usefulness of System Hungarian whereas I can see some benefit of App Hungarian if properly applied on the variable scope – read more about it at Joel’s).
The problem rises when there are multiple nested blocks, what’s now the scope of this “l_” prefixed variable again? You simply don’t know until you back track it to the declaration of that variable.
That’s where qualified names come in pretty handy, let’s examine:

create or replace package pck
as
  procedure p1 (
     text in varchar2
  );
end pck;
/

create or replace package body pck
as
  text varchar2(10);
 
  procedure p1 (
     text in varchar2
  )
  is
  begin
    pck.text := p1.text;
  end p1;
end pck;
/

Note that in procedure P1 we use qualifiers for the variable and parameter TEXT. Even though they have the same name, the scope is very clear. We could even qualify the parameter with the package name which would make it a bit long, e.g. “pck.text := pck.p1.text;”
Isn’t this beautiful? Absolutely, but as soon as we use long package, procedure and variable names it can make the code somewhat cumbersome to read as you end up with very long expressions. In my opinion I think the benefits of qualified names far outweigh the disadvantages of having a bit longer code lines – you can look at one (maybe big) line of code and you have all the information, no need for scrolling up to the declaration to find out the scope.