What do you think are the most bold reasons for using a unique user panel URL for each customer?
For example:
customer1.serviceprovider.com
customer2.serviceprovider.com
In what cases should this scenario be used instead of panel.serviceprovider.com
The purpose of the 3rd-level domain (username.company.tld) is to give users their own URL context.
By own URL context I mean not only public profile (as it was already mentioned here), but rather a way of keeping semantic-only information in path part of the URLs and moving owner information to the 3rd-level domain (i.e. grouping the data associated with the customer or company or whatever and using 3rd-level domain as a key to that data).
Many blogging services uses such a scheme (LiveJournal or Blogger to name a few), so, for example, profile page of any LiveJournal user will have an URL like this:
http://username.livejournal.com/profile
Where 'username' is the name of the LiveJournal user and '/profile' is a data associated with that user. Post URL will have the same structure.
So, if your service main purpose is to store or manipulate user data (blogging, project management, image storing, etc) rather than to provide some generic functionality (search engine, news, etc) it may be a good idea to define such contexts.
AFAIR some time ago where were some security benefits (or at least talks) of handling a 3rd-level domains (and assigning auth-cookies to them and not to a parent domain) but it seems like it doesn't improve security nowadays.
Many services use user handles in their URI's to give customers a link to their public profile they can share. The same holds true for using subdomains. It gives the user a unique identifier by which to reach their profile on the service's domain.
Using subdomains instead of URI/folder structure could be choosen merely to stand out from other services, or for a preference in technical implementation. It does carry a slightly different semantic meaning and search engine value to have a user's profile be implemented as a subdomain rather than an identifier or folder in the URI structure, but it is a marginal difference at best.
Use a custom subdomain name when the service that the user is accessing is private, that means not everyone can sign up for a user account for accessing the subdomain area.
Examples:
Basecamp - you can go to the main website to sign up an account for to manage projects, and it will be private, only the chosen users can log into your project management page.
Wordpress - everyone can make a blog, but not everyone can sign in/up to a particular blog because it's a private.
I don't think this is worth doing for the most part.
Typically speaking, users are abstracted away from URLs. They go to yoursite.com, log in, then just follow links. Other than that, users never handle or care about resource identifiers. In fact, if they're using a mobile device, they won't be able to see the URL even if they want to, because most mobile browsers hide the address bar as soon as the page finishes loading.
The only time I would provide a subdomain is if your users are sharing their service with their clients, and need to give out a recognisably unique URL. Free web hosts do this, for instance.
If you wish for users to feel that a service is "theirs", you'd be better off using custom branding and styling your service after the customer's organization.
Many eCommerce sites segment their audience based on which marketing material prompted them to go to the company's website.
This allows the marketing department to determine the response rate for different marketing material (A/B testing) so that the winner can be used again.
By tracking a certain customer's movements through a website the company can determine how serious a buyer they are and what specifically the user is interested in to allow better targeting of future marketing material.
