Different lock types on source table when I change method of inserting data? Why do I encounter IS(intent shared) lock on source table when I insert into target table using SSIS data flow task and S(shared) lock for same task when using T-SQL statement?

I am trying to insert around 10M rows. Concurrent inserts on the source happens all the time. So, according to lock compatibility matrix, SSIS data flow task does not block parallel inserts, but T-SQL insert does.

Why is that?
When you use SSIS, the target and source are separate operations. As far as SQL Server is concerned, it sees one connection performing a simple SELECT and another connection performing a bulk load or regular INSERT.

The simple SELECT can benefit from a locking optimization where row-level shared locks are skipped when safe to do so. This leaves only the intent-shared locks at the page level.

When the insert and select are combined in the same T-SQL statement, a different execution plan is produced, and the specific locking optimization is not applied.

If you wish to produce the same non-blocking behaviour on the source table when using INSERT...SELECT, you would need to use a row-versioning isolation level. 

Read uncommitted isolation would also not take shared locks, but offers very few consistency guarantees, and might even throw an error when the data structures underneath the scan are modified (error 601).