I do not believe you would need a new admin account. While I can't say for certain what happened with your previous upgrade, in the past I have not had this issue if I made certain that the old K2 server had the blackpearl service stopped and disabled (so it doesn't accidentally start back up) before I install K2 on the new server pointing to the same SQL database. If two blackpearl services are running against the same K2 database at the same time it would certainly cause some unusual behavior.

While this may not be needed, I also go through the K2 database tables looking for references to the old K2 server and eliminate or rename them to the new server. Just to make sure there aren't any lingering links to the old K2 server.

Personally, I would be a bit more cautious and would make sure that you upgrade the Dev server the same way that you're planning to upgrade the Live server.  That way you hopefully will work out and document all the issues during the Dev upgrade before you attempt Live.  You shouldn't need to redeploy forms or workflows as they exist at the database level and you'd be connecting the new server to the existing K2 database for their respective environments.

I also don't think changing the admin account had any affect on the last upgrade problems.  Changing the service accounts could cause access issues but even then I couldn't see it sending out previous completed tasks and such.  Makes me wonder if the K2 database was restored to an earlier date for some reason?  Or if you have a process automatically kicked off based on some external data and that datasource was reset.  Of course, that's pure speculation on my part.

As I'm sure you know without restoring the K2 database you lose all the previous reporting and audit information and any in progress workflows.  Unless there was some big problem with the database that couldn't be fixed by K2 support I can't see why you wouldn't use the same K2 database.  There would be no need to deploy the forms and workflows and the business users could continue working from where they left off.  Most customers I've worked with have been using the same K2 database for 5+ years or more.  If it gets too big you can archive out reporting information (K2 4.7 not K2 5).

I would use the same K2 service account unless there is some compelling IT reason not to.

Using a new K2 database probably caused the problem that workflows were restarted as I suspect conditions that existed in the old K2 database to determine when a workflow should start no longer existed causing them to start again .  This isn't out of the box behaviour so I speculate that there is some schedule or service that automatically starts the workflows.  It would be good to look into the workflows that restarted and see how they're started so that you can document the conditions.  If its simply users submitting a form then my speculation is wrong.

Are you using smartactions? If you're using smartactions, and if it's linked to the K2 Admin account's mailbox, and reusing that K2 Admin account on a new K2 server, everything in the K2 Admin's inbox will be treated as new items on the new K2 server, which will then process everything accordingly and the server replies will proceed to block out the sun and plunge everything into darkness. 

That being said, K2 DB migration is a common exercise I see most customers doing when they have new servers and whatnot. Main reason being they don't want to lose previous workflow data and they have existing instances that have yet to be completed. Basically continuity.

When done properly, reusing the K2 DB in a new server will have no issues.