DB: Having redundant fields in Table
For proper relational design redundancy should be avoided - anything that can be derived from other data (looking up the user that relates to an advert in this case) should not be stored separately again. This helps enforce the integrity of your data, stopping bugs in your code allowing and with appropriate keys and indexes the performance should not be noticeably impacted.

As we are not in the perfect world assumed by theoretical models with perfect implementations of those models and AI to interpret any query we throw at the database, it is sometimes advantageous to de-normalise your data in the manner you describe for a performance gain - but best practise is to only do this once you have identified a specific performance problem rather than baking it into your design. Never de-normalise your data purely for conveniences sake - instead define your tables in normal form and create views to reduce query complexity in other layers of your code.

Of course if you intend to allow messages about an advert to go to other users, a complaint perhaps which would go to an admin initially and not the user who placed the advert, then you must include the destination user as a specific property as it can no longer be unambiguously derived from other data.