Slow Trigger performance when big batches
I'm putting this here since it's a bit long, but I don't think it should qualify as an answer.  There are no answers here, just observations and advice.

Short version, there isn't anything that can be done to make the query go faster and achieve the same results.  You need to change the process that is feeding data into the main table if you want batching to solve the issue.  Otherwise, you have to change the history process.  

First, it's not the table insert that's slowing you down, it's the query that pulls the INSERTED and DELETED tables together.  

Why Not?

The INSERTED and DELETED tables are heaps with no indexes.  Joining them together as you are doing requires two table scans and a sort.  The larger the operation, the more expensive this gets.

Batching Inside the Trigger

This won't help you here because the source tables are heaps.  You can't walk them without creating some sort of key to work with, and adding anything will just increase (at worst) or just increase complexity (best case) without improving anything.

Batching Outside the Trigger

If you can rearrange so that you are doing smaller update statements at a shot outside the trigger then the INSERTED/DELETED tables will be smaller, making the operation faster and less blocking, although total cost will be the same.  

Solution(s)?

Any solution that addresses this will require a change in some fashion.  You don't mention your version of SQL, but if you are on 2016 or better, you could look into temporal tables. https://docs.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables?view=sql-server-ver15

Alternatively, for this type of history table, where you only want to catch the UPDATES, I would do a straight insert of the DELETED table contents.  No additional comparisons or joins with the INSERTED table.  Your cost should be roughly the same as the insert, so minimal increase (I mean, double the I/O, but that's as minimal as you can get).

Then for looking at it, you just grab all the history records + the live record and you can see what changed and when.  It won't have that "ChangedColumns" list that your current version has, but you could put something like that together if you want.

Good luck.