Coming from the standard "folder tree" and the "bins / clips" paradigm in legacy NLE's, I, too, had trouble wrapping my mind around the "events" structure. But, I came to understand it with some historical research.
Allow me to wax philosophic: (or just stop reading now)
In adopting "events," the FCPX engineers were following Apple's IOS convention with regard to their consumer electronic devices--i.e. iPods, iPads, and iPhones. (There is a school of thought that, in the future, OS and iOS will merge into one operating system.)
In iTunes, when we import a song, we are creating a file that will forever be seen as an "event" by the application--created on such-and-such a date, at such-and-such a time. That's the ONLY way the app sees it. Now, we--the user--may assign a song to our "favorites" playlist or to a "punk runk" playlist. But, those are ony labels as seen by us humans trying to organize everything. On a deeper level, the IOS ignores all those superficial labels. It keeps its eye on the original "event." When we drag the files around or push them to other devices, it stares soley at each "event."
Thus, in FCPX, when we create "keyword" lists or "favorites" or "smart folders," that is OUR way to organize the media. At the end of the day FCPX sees each file as a singular "event." We can move them, name them, stick 'em in folders, but FCPX still keeps track of the "event" as it was born into the system at a particular time.
The "events" structure also keeps us users focused on the interface, not the OS.
Unlike other NLE's, FCPX doesn't want us "looking under the hood" when it goes to copying files. In legacy NLE's, we were used to going to the Finder / HD to copy files from one folder to another or to drag them to an external HD.
Although we still have the option of doing it that way, FCPX would rather we do all the copying and such INSIDE the application. FCPX worries about where the files exist in the folder tree--again, as they relate to "events."
