In my opinion, the main issue with raising "bugs" in this situation is that you have no idea what their testing scope for the site was. You don't know which browsers/devices it was developed for, you don't know which versions of those browsers were supported at the time it was written, you don't know any of the business logic behind what was done or why.
Without knowing what criteria you are testing against, how do you know if the site passes or fails? A QA who is going to raise issues that they consider to be bugs which are, in fact, outside their testing scope could be problematic. It's a waste of your time as a QA to be testing things that are out of scope, and it's a waste of whoever's time the ticket gets assigned to who (at the very least) has to point out that what you're testing is out of scope. While you might view this as being pro-active, it could be a red flag that you're going to be spending your time digging into things you haven't been asked to look into, without the context you'd need to understand them, and creating unnecessary extra work for your team as a result.
The other issue, as the other answers have touched upon, is that you risk appearing to be negatively critiquing the work of the people who are hiring you. This is definitely a double-edged sword. You want to appear knowledgeable but you definitely run the risk of appearing condescending. Many people don't really take criticism well, and if the people in the room were responsible for the work you're criticising, fair or not, that's unlikely to go down well for you.
I would say it's reasonable to prepare a response in case they ask you to critique their site (but temper your language so that it doesn't come across too negatively, and maybe just flag one or two issues even if you find dozens), but I probably wouldn't offer this critique unrequested.