I am having trouble understanding whether it is best practice to write acceptance criteria in the given when then format or if there are some scenarios in which this is counterproductive. Let's say one of my acceptance criteria is that the application should have the same look and feel across the screen and be mobile responsive. Should I reword it somehow to the given when then format?
Requiring a specific structure for acceptance criteria is often wasteful, so I encourage teams to understand different structures for capturing their units of work, their acceptance criteria, and their definitions of done. Although the given-when-then structure could help a team to make sure that the acceptance criteria are clear and precise enough to act upon, there are edge cases (and you have found one) where trying to force the structure could be more difficult and end up in a loss of clarity. Making sure that the acceptance criteria are easy to read and understand is far more important than sticking to a structure.
In your specific example, conforming to a user experience standard or a design system is a clear need. Responsive design is a well-understood concept. I'm not sure how you could format it in the given-when-then structure without adding verbosity and making it harder to understand what it means for the work to be done and acceptable. However, this could be a good conversation with the team, such as at a retrospective. Present the acceptance criteria in different formats and capture it in a way that helps the team understand what they need to deliver.
Common sense is the best! however, personally, I find checklist pretty helpful... help people to write short acceptance criteria and it helps keeping the testing progress.
Another trick is to ask yourself, what do I want to get from this task? the list of things you want to get is the acceptance criteria.