Big size difference in ibdata file from live to staging
One possibility is that you have or had in the past innodb_file_per_table=0, and despite separating them at a later stage into separate files (changing it to 1+rebuilding the tables), the space, as you said, has not been reclaimed.

In most cases, ibdata1 growing too much is caused by extra temporary space needed in the UNDO area (which before 5.6, was always part of the ibdata1 file). The usual problem happens this way: A long transaction starts (a long running query, a non-closed transaction by mistake, etc.)- all subsequent edits cannot purge the old data because in repeatable read mode, a transaction after the first select goes into "snapshot mode". As a consequence, the UNDO space keeps growing and growing, and your queries start getting slower and slower. This is very typical in production hosts that have high write activity but also have to backup consistently the database or perform statistics-like queries.

There are other reasons why this could happen, but the long running transactions is the #1 cause (aside from former bad configuration). If the long running transactions are no longer active, know that data is available for new pages within the file, just not returned to the filesystem- so unless it happens again it may not grow again. As you said, either export+import is the only way to shrink it before MySQL 5.6.

You have more information on how and what ibdata1 is used for at: https://www.percona.com/blog/2013/08/20/why-is-the-ibdata1-file-continuously-growing-in-mysql/ Many of the pains of tablespace handling were fixed on 5.6 (UNDO on an external file, importing/exporting .ibds, querying ibdata structure contents,...) so give at some point a chance to 5.6 testing, it may be worth in your case.