This is a great question; I had dig around a lot to determine what capabilities and best practices surround the new DX file structure. I don't recall my sources on what I learned, so I can't list them here. But here's what I found through research and trial/error.
First, we have a great deal of freedom in designing the structure, but the weirder you make your DX structure, the more likely it is that you'll encounter a DX quirk / undocumented limitation. In the structure you listed, "force-app" is similar to the src directory in that all source should (as a best practice) go under one central directory. This helps with e.g. managing the project as a git repository etc. In terms of the name, I also didn't like it, so I went with "sfdx-source".
The meaning of the next level is up to you. Because I have multiple packages in my project, I made one directory per package. Within those packages, you can organize your directory structure in whatever way you like. Here's an example of how I structured things:
The key is that you need to maintain a "default" directory for metadata that is created through the UI. For example, if you create a new object in a scratch org, then download the source to your local machine, SFDX needs to know where to place that object.
For my preferences, I wanted all metadata/code to start in an "unpackaged" directory. When I was ready to add the metadata to a package, I would move it to the appropriate package directory (through a file browser). The one "gotcha" I experienced with this is that SFDX has trouble with moving object metadata from one place to another. As of the last time I worked in DX, every time I needed to move a new object to its final home, I had to recreate my scratch org in order for the metadata to properly sync again.
The package source directories are defined in sfdx-project.json. You specify a root directory for each package, and the system will act appropriately regardless of how you choose to organize it. The only "package" that requires a particular structure is the default package. It may be possible to change the structure or names of the folders there, but from everything I've seen you have to have a "main/default" directory in the default package.
Here is what my JSON looks like, corresponding to the directories previously shared:
Finally, concerning main and default, these directories do not need to be empty file-wise; you can move metadata files into those directories if you like, or (more likely) include non-metadata files like a .gitignore. The system will parse whatever directory structure is there, and deploy any metadata/code with the appropriate file extensions. The only difference between main and test is that main is a special directory that contains the default directory. test on the other hand is a directory to which you might move any apex tests after they were created in main/default. In my case, I prefer to have all my unit tests in the same directory as the classes that they're testing, so I don't have a test directory.
