Every change that causes update of the content database for that site collection will update LastContentModifiedDate, LastSecurityModifiedDate or both. That means almost every change you have mentioned.
Only changes in file system will not update the content database. That means changes in SharePoint root folder (application pages, resource files, feature definitions etc. ) will not update the database. Also, changes in the virtual directory will not update the database (for example web.config file).
You can think from another viewpoint to have a better idea: What is retained when doing database attach to another farm is retained because it has been saved in the content database.
LastContentModifiedDate is updated very frequently. For example if auditing is enabled then LastContentModified will be updated event when viewing an item that has audit flag on.
Comments to your bullet points:
• changes to the definition of lists/fields/content types or just the content stored in them?
Yes. I would call them settings instead of definitions because definitions are in SharePoint root folder but their instances and their settings are in the content database
• changes to People/Groups/permissions?
Yes. Every user/group added/removed, changed permissions anywhere in SPSite will update the content database but should be tested does it update SPSite.LastSecurityModifiedDate only or LastContentModified too
• changes to which features are activated?
Yes. Again, feature definitions are in SharePoint Root folder but activated/not activated state per site/web is saved in the database.
• changes to site Title, Description, logo?
• changes to anything/everything under Site Settings?
Yes, I can’t think of anything in site settings page that would change the file system instead of the database (I am talking for out of the box, not custom solutions).
I have not tested everything said above but this is how things work/should work.