Durable keys are important because you don't want to have to update all the existing records in a Fact table if the key in the Dimension table changes. Dimension table keys should also be separate from the "natural" key or foreign key used in the OLTP system because you will need to represent the data at different points in time for your type 2 slowly changing Dimension.
Say you have a customer John Doe who is CustomerID 12345 in your OLTP system. If he lives in Ohio in 2018, then moves to Kentucky in January 2019, you would want to know both of those addresses in your Demographics Dimension table. Any orders he made in 2018 should be reflected in Ohio, and any orders he made in 2019 should be reflected in Kentucky, so different records in your Fact table will point to different records in your Dimension table based on what was current at the time the Fact occurred.
If you try to use a multi-column key, you will end up making the Fact table wider than it should be. Your Fact table will typically be narrow (few columns) and long (many rows), while your Dimension tables will typically be wide (many columns) and short (fewer rows). You would also need a way to distinguish the different point in time records for the same "natural" key, so you might as well use a single surrogate key anyway.
I also agree with Martin that there are better ways to handle type 2 SCD than the SSIS transformation task. Take a look at what you can do with the MERGE statement OUTPUT clause: