Compression setting not effective for differential backup maintenance plan?
Community wiki answer:
Checking compression
You can check if your backup is compressed or not. There are a few methods in How can I tell if a SQL Server backup is compressed?.
You can also check the value of compressed_backup_size and backup_size column of the backupset table in msdb. For example:
SELECT
    database_name,
    type,
    PctCompression =
        CONVERT(NUMERIC(20,2),100 - (compressed_backup_size / backup_size) * 100)
FROM msdb.dbo.backupset
WHERE ...

The update to your question shows that the differential backup was indeed compressed.
Backup larger than expected
That 10GB of data could be spread over a lot of pages, and those pages could total a great deal more than the 10GB you inserted (especially with poor clustered index choices). Note also that differential backups operate at the extent level, so any change to any page within an 8-page extent will result in the whole extent being backed up.
Check the log_reuse_wait_desc after doing log backup or use dbcc opentran. If there is an open transaction since yesterday, your full and differential backups will be larger due to the included active log.
There may be no open transaction now, but if a long-running transaction was active at the time of differential backup, the backup file size will be more than expected.
The fact that your log grew to 500GB (and you take regular log backups) means the log could not be cleared for long time due to something (probably an open transaction). All the log associated with that transaction was added to the differential backup.
If you want to check if it's so, try to restore your database into another (new) database, perhaps on another server. This way you will do 2 things:

You'll verify your full and your diff backups; and
You'll see how much time your differential will take to restore.

If the differential takes a long time (e.g. 3+ hours) it indicates a lot of time was spent undoing the effects of a long-running open transaction.