Your current process shouldn't really change application performance (especially with such tiny amount of data) but perhaps your database gets severe index fragmentation and creating the new database results in the indexes being rebuilt. (We wouldn't be able to determine this without more information such as a before and after execution plan for a specific query that improved due to your process.)
In any case, you can run the same shrink commands on your existing database, no need to export and recreate a brand new database every time. Though usually it's not recommended to shrink a database, in your use case where you're bound to only 10 GB per database, I understand the potential need to do so.
In the long term, I'd look to re-architect your application and database to use multiple databases if possible and makes logical sense, as a way to work around the hard cap of 10 GB in SQL Server Express. (E.g. group only certain related tables in one database and other groups of related tables across other databases, or decouple transactionally heavy tables from your less changing ones for another way to slice it.) Cross database querying is always allowed. Or you might find it worth it to purchase a small Standard Edition license eventually.
Furthermore, you might want to consider switching your database to Simple Recovery Model which will reduce the amount of space needed by automatically reclaiming the space used in the Transaction Log. This is likely all the space you're reclaiming with your current process when you run the shrink command, and therefore will likely remove your need to run the command anymore.
Regarding keeping your indexes defragmented, you should read up on Microsoft's BOL: Optimize index maintenance to improve query performance and reduce resource consumption and then you can look into Ola Hallangren's SQL Server Index and Statistics Maintenance which will help you automate that process to ensure your indexes are maintained.
All of this is fine to run in a production environment, but my advise is to always test in a development one first, come up with a game plan that works, then implement it in production.