Lots of teams choose to keep their Maestro tests alongside the code for their application. That way, a build from a few months back that now needs a patch also has the correct version of the tests sat with them, and a new feature branch that changes how login works can have the changes to the test flows developed right alongside.
But what's a good way to lay this out?
Boring tester answer: it depends
Journeys
If you arrange your tests as journeys through your application, then you likely want some top-level folder to contain them, and only start organising them into deeper subfolders once they become unwieldy. Maybe you end up with something like this:
Which later spreads into something deeper, once you decide to start splitting. Here, I've broken this up between flows centered around new and existing users, and an extra folder to contain utility scripts that might be shared.
For testing approaches that are centered on validating the behaviours of individual features or requirements, you might choose to mirror the source structure, so that the tests are easy to find and maintain: