This is my take on things:

- If you have some information that is likely to be listed, sorted or categorised, you can create a page type for it. You can add and change page attributes to create the 'fields' for the data. The composer then makes it easy to create forms for entering such information and these are very client friendly. Some examples would be: products, events, businesses (like in a directory), categories, news items, blog posts, gigs, case studies, portfolio items.

Often I see a straight mapping between database tables to page types and table fields to custom page attributes.

- If some 'chunk' of information needs to be consistently formatted across pages, but they're smaller in nature and don't need listing/sorting/categorisation, then a custom built block is often suitable. It can also be suitable when you might have a one to many relationship with a page, so it makes it difficult to achieve with page attributes. Some examples might be: photo galleries, testimonials/quotes, photos with captions.
If you create something as a block, it becomes much harder to then try and list all the blocks across your site in one place - so I'd always consider the page type approach first before committing to a block. A block is also a bit more hard coded in terms of fields, whereas it's easier to add additional page attributes for a page type.

- If you have a particular page on your site that needs to do processing, effectively doing more than just outputting content, then this is where single pages and page controllers are useful. This could be a search facility, a specific form or wizard, something that retrieves data from anther system/database, reports. Where it needs to be more administrative, it's a single page in the dashboard.

- If you need to store and manage data in your system that really can't be handled by page attributes and custom blocks (such as database with more complex associations), then you can consider adding custom database tables and more manually managing this data using single pages, dashboard pages and custom controllers.

- If you have a membership/sign up process, it's always worthwhile investigating the built in users and member profiles for concrete5. Users can be given custom attributes (which can be turned on and off of being mandatory, on the registration form) and pretty much all of the registration/login/profile processing and display can be overridden.

So in your case, you might use the built in user registration process to initially register members, then you might redirect them to a single page where they input more custom information. This info could be stored and retrieved in some custom database tables, using concrete5's API where useful.

That's my current view of things anyway!