What kind of memory and HD space leak problems can this structure give
us in MySQL-InnoDB?
Given your description it's impossible to give any meaningful value to memory or storage requirements. You say "16 million per year" but what is that? 16 millions rows/tables? With no schema example it's still impossible to estimate. For tables you do have you can run
select table_name, data_length, index_length, data_free from information_schema.tables where table_schema='mydatabase';
To get a feel for current storage requirements. What you'll be more interested in is growth rate over time though to ensure you're not going to run out of space in 3months down the road. MySQL doesn't give a built in growth rate metric so that's something you'll need to periodically poll and record yourself.
For memory requirements, in a perfect world your innodb_buffer_pool would be big enough to accommodate all your data and indexes in memory. It's never a perfect world though and can become impractical or cost prohibitive to have such a machine. At the same time, strive to make the buffer pool as large as you can to keep most frequently accessed data in memory.
If you are straight up dropping tables the storage space will be reclaimed to the file system if and only if you are configured with innodb_file_per_table = true. Other wise all your data is stored along with metadata and transaction history in ibdata1.
Is this a good practice or should we consider a structure change?
It's not unheard of to offline old historical data. However your description makes it seems like this becoming active is some what common. I can't imagine any on demand process where you have to rebuild a table before being able to service the request.
Rebuilding a table and it's indexes is much slower then a raw copy of a file of similar size to the final table.
You say it's being "packed" and "unpacked" indicating it's still being stored somewhere. If it's going to be needed to be accessible by an application just keep it in the database and let old pages fall out of the buffer pool. When requested again the information needs to be read from disk versus having a table completely rebuilt.