Any news?.... such an important issue.. can save hours of manual work  

It would be better to have an option that the user of jcma can decide what to do, like thzere is for the e-mail addresses.
We had a case where we intensively used 'Migrate all' at first, to be able to fix any system based configuration in cloud, before we did a 'Choose what to migrate' of single batches of projects to make it possible to spread the user experience and workload over a view weeks. This to make it possible to give the neccessary time to the users after their project was migrated, in a very large jira enterprice level instance.

Unfortunately, the values of the fields where migrated to (migrated) labeled fields even though the project was deleted on cloud and therefore should not be the case here, because there is no existing data and all fiueld configurations are exactly the same. We however learned afterward that JCMA is kind of 'stupid' and only looks if there is a mapping table. If not, it presumes that the fields are different, in stead of checking for fieldc onfiguration and the presence of data. If it should have done that, is would have seen that there is no field config difference and no data in these fields and just could use the already present fields to migrate. 
To me, it looks like Atlassian has taken a shortcut here, not doing real investigation in JCMA if configs are the same. and fields/configs can be reused.
In my opinion, it is just another 'bad developer job'.

https://getsupport.atlassian.com/browse/MOVE-147881 

I could understand the duplication if it's the same field type, but I have fields that are different types but the same name with the "migrated" suffix. That creates and extra step for admin to remove that text so that filters don't break.

For anyone else landing here due to this bug/"feature" what I ended up doing for our DC to Cloud migration was to purge everything that was removable from the destination Cloud instance.
eg. roles, schemes, custom fields, priorities etc (just leaving 1 of each that wasn't causing a duplicate - as you can't have an empty list for most of these)

This helped a lot with reducing the amount of duplicated items that would have needed post migration fixing.
There's nothing you can do about the example  shown on this suggestion as "Start date" is a locked field but can you do this for most other items.
Obviously test this first in a sandbox migration to ensure it works for your data, but it ended up saving me a lot of time and effort during my production migration.

If you need to do a dummy project migration + extra dark features to fix something else like multi project boards/filters you will still likely end up with duplicated items, however they won't be associated to the production projects so it's a lot easier to go through and remove these afterwards.