If I'm reading the screenshots correctly, I'd guess the update involved some restructuring of the database which involved some data being recreated in its new structure then deleted from its old structure. That would mean that the database would have had to grow to accommodate the temporary duplicate data but then hasn't been shrunk afterwards. Similarly, if lots of rows are being updated, lots of data will be getting written to the transaction log. The contents of the transaction log will have been cleared when it was next backed up leaving lots of space reserved for the transaction log but not a lot of it in use. I suspect the size of the data is probably similar to what it was but the amount of allocated space has grown. If you're struggling for disk space you could probably shrink both the DB and the transaction log however growing them is fairly resource intensive so, if you've got the space to spare, it might be worth keeping them at their current size to allow for growth.

I am not aware of such change. Could you run the db shrink command to see? 

https://learn.microsoft.com/en-us/sql/relational-databases/databases/shrink-a-database

I think the size of database / log is probably fine - we're using Azure SQL, so it will automatically shrink the log.
However, the deployment of the upgrade required significant bump up of SQL resource (we've scaled the pool to 40 cores) to even execute the migration in reasonable time (about 25 minutes).
To me it doesn't look normally, even the upgrade from Episerver 11 to Episerver 12 wasn't as resource heavy as the Episerver 12.15 update.

Right. In 12.10 there was a migration of tblContentProperty and tblWorkContentProperty - essentially rebuilding those tables. If your tables have a lot of rows that can be slow. Nothing we can really do at this point, but it's good that you brought it up so other devs are aware of this