A "folder", in LR, is really a "catalog", because LR needs to import image into first. No it isn't.
Note the quotes. I never said it's a file system folder or the like. A "folder" is just a container for "documents" to be kept together for some reason.
In LR, the "documents" are the images, and the "container" is the catalog. What LR got rid of, is the hiearchical structure of "folders within folders", because such a structure is not flexible. You can open a single "folder" (catalog) at a time, exactly like in any file browser you can usually work on a single folder at a time (not many let you work on subfolders also at the same time, because it can be confusing for most users). Then you use the documents attributes to search, access, and organize them the way you like, without having an inflexible hierarchical structure like a file sytem has.
Back in the old days when document were really stored in folders within drawers, many complex "indexing and retrieval" techniques were developed to access them when a seach implied the need to access several documents across different folders and drawers, because a physical storage can't be multidimensional, and storing different copies in different hiearchies is not usually an option because it would require more space, and they could easily get "out of sync".
The first databases adopted the same hierarchical model. Then, one day (in the '70s), a man called Ted Codd, working than for IBM, proposed a radically different model, the "relational" one. In this model data are not linked (and seached) by parent/child strict relations only, but can be linked (and searched) using different relations based on the data "attributes".
For data that don't have a single search/access path, this method is far more flexible and faster. Actually, a file sytem is a hierarchical database. Where you can get lost, that's why most moder OS index it into a far more manageable database to allow for "find" queries based on file attributes like date, type, contents... in theory a far different file system could be designed, Microsfot thought about it - a file system based on the SQL Server engine.
The image "documents" exist in exactly the same entity in LR and Aperture, both allow you to form your own folder structure or rely on the program to create a year-month-day based folder structure to contain the image "documents".
You can reference those images alone if you either apply specific exif on import or if you apply a year month day search.
Both programs work the same. You can use a more intuitive folder naming strategy that enables simple location outside the proprietary database, or you can throw your lot in with the database and rely on that to keep track of everything thereby letting go of the ability to make any image location unless you know the specific date the camera calender was set to for that image.
I think most people find the more intuitive route more intuitive, but to be sure, you can make both programs work identically from an image "document", folder, database "catalog" point of view. Indeed it doesn't impact either program if you have 10,000 images one in each of 10,000 separate folders, or one folder with all 10,000 images in it. For technical reasons the later is rarely used because document/image extensions get repeated too frequently without further import management.