Objects are not actually stored in libraries. They're really nothing more than lists, but it's easier to refer to an object as being "in" or "stored in" a library. An object can only be stored in one library at a time and there are commands to help move objects around. Libraries cannot be stored within other libraries as they're designated as "system" objects. They're made to appear as if they're stored in the QSYS library. Other "system" objects include user profiles (*USRPRF), configuration objects (*LIND, *CTLD, & DEVD), etc.
Qualified Objects
On a CL command, to reference an object in a specific library one would specify the library name first, followed by a forward slash, and then the object name (ie. MYLIB/MYOBJ). This is called "qualifying an object." In almost every AS/400 shop it's the rule that programs mustn't qualify objects unless it can't be helped. Programs should always depend on the job's library lists to find objects unless circumstance dictate otherwise, such as in emergencies or if the program is temporary, like a fix program or a kluge.
Shop Standards
On systems with hierarchical filing systems the norm is to have many directories, most of which are contained one within the other, and with a moderate numbers of files in each directory. Since libraries cannot be stored within other libraries on the AS/400 and because historically the library list was always so small, the opposite became the norm; small numbers of libraries each of which contain large numbers of objects.
Most homegrown applications have between one and three libraries. Some have program, source, and file objects together in one library. With shops that have a huge amount of data and a small backup window they usually split the database files into a separate data library and keep the source and programs in another library. In companies with a separate development systems they tend to split it further by placing the source into its own library.