Production to me is the client's server, where the site will be live.
A lot of times in my work, there's already a site there, perhaps not Wordpress, but there's already a live production site there that I am updating (design and platform perhaps).
I don't think it's good practice to interrupt that live site with a "maintenance" page, and also someone *could* possibly hit the "Welcome to Wordpress" installation page at the exact moment I would be installing Wordpress directly on the production server... that to me is bad practice. I'd rather the client have a seamless go live, no maintenance page, no downtime, just an *almost* instant swap to the new site.
So typically everything happens (and yes, sometimes content entry) off of the production server, so the client can see the "new" site in it's final state (content and all) before it goes live. In my experience, this is typically on a dev or staging server owned by the ad agency I'm working for. Or when I work for myself, I develop locally, then push to a dev/staging server I own, we sometimes do content entry there, and finalize everything for the client to review at that location, then push to their production server for go-live once everything (content + design) is approved.
Once client approves, the site gets moved to production - aka the entire wordpress filesystem gets moved (because they might not have had Wordpress before) and then the database gets migrated to the production server. This is where the issue lies. Since we aren't developing directly on the production server, nor are we installing directly on the production server, a compatibility issue arises. Because locally/dev/staging I did have a higher version of MySQL, but my clients production server did not.
This is my typical workflow, and the workflow I've seen in my 8 years of building websites.