Well, the fact that you experienced the same problem as I makes us members of a club that I'm sure neither of us wishes to belong to.
I eventually installed my site successfully using the WP Clone (WPC) plugin. It took longer than my usual method of moving a site from a local to production server. I am glad that this only involved a move to a test production server. Here are the steps I took to resolve the problem.
1) The large site backup (BU) zip file created by WP Clone (WPC) tipped me off that something was amiss. Sure enough, there were several older BUs of files & db included with my site files that I eventually deleted.
2) I also deleted the large (650 MB) BU created by WPC from 'wp-content/uploads/wp-clone'. At this point, the site was down to a size I expected (~190 MB; files & db).
3) I made a fresh BU of both site files & db using the 'Backup WP' plugin. Then moved those files outside my dev directory ('htdocs' in MAMP), thus emptying the 'wp-content/backups' directory.
4) Then made a fresh BU of the dev site using WPC. Zip file size was greatly reduced (650 -> 190 MB).
5) Pasting the BU url into my target site on the test production server returned the same error message as before. It was necessary to manually upload the WPC BU to the target 'wp-content/uploads/wp-clone' directory on the production server.
6) I discovered that my ISP set a 5-minute limit on file uploads via SFTP. Unable to upload the zip file via encryption, I resorted to unsecure FTP. That worked. Now I need to find out how to get more bandwidth from my ISP.
7) Using WPC on the production site, I restored the url. Unfortunately, not all the content from the site transferred. There were whole blocks of text cut off from pages and posts.
8) On a hunch, I imported a BU copy of the db file through phpMyAdmin, overwriting the db tables installed by the WPC restoration. I checked my 'wp-config.php' file, and the connections called for between the WP install & the db were proper.
9) I checked the test site, and I kept being redirected to my localhost site. This suggested that references in the test production db to the localhost url needed to be changed to the test production url. Thankfully, interconnectit.com's 'Search and Replace DB v3.0.0' tool helps with changing these references. Unfortunately, the process of changing url's with their tool took longer than usual, and threw a couple of errors which I've never seen before. After globally changing most of the url strings, I had to go in & change 2 db table rows using the S&R tool.
10) I then checked the site, and everything was up and running. Changed the permalinks and reactivated the plugins, and everything was good to go.
Would I use this plugin again to move a site? I would be willing to give it a try one more time using a different hosting company. The obvious pinch points were:
a) Inability to quickly restore a dev site on a production server using the WPC PI.
b) Insufficient bandwidth to move the WPC zip file up to the production server via SFTP.
c) Necessity to overwrite the db following the WPC restoration to install all the content.
d) Extra steps and time involved with changing url strings in the db.
On balance, I think my 20-step checklist of moving a site would work just as well, and take less time (about an hour).