Disclaimer: I am a software engineer, I do code reviews, and I am nitpicky like this. This is why.
Without knowing precisely the issues you're having, a lot of these comments make sense to me from a code review perspective. Good, expressive variable names are important to code readability. If I have a variable called x, you have no idea what it does. If I have a variable called myApiResponse, that tells you:
1) It is an object.
2) It is a response from an API
3) The API is (probably) called MyApi
These are good things to know when reading and following code flow and are important for code maintenance. If your variable names are being called out, it's probably because they don't contribute to code readability and are going to cause problems in the future with maintenance. These things matter.
Likewise, putting things where they are supposed to go is important. Let's say you have a large application, a part of which is processing orders from your customers. So you have a CustomerService, which handles customer data, and you have OrderService, which processes orders. Let's say you need a customer's credit card information (for whatever reason you're storing that in your dataset). But you put your method to access that information in your OrderService, because "after all", the order service needs it. But then, you have another service, let's say your customer service dashboard, which also needs customer credit card information. But the person building the customer service dashboard doesn't know that order service implemented this function already, so they check CustomerService (where it should be expected) and don't see it and they go ahead and implement it. Now you have 2 implementations of the same code that have to be maintained. Suddenly you've doubled the code maintenance load of your feature to get customer credit card info, which you could have avoided if you'd just put the functionality in the right place where it belonged.
These are important things and they need to get called out in code review so they can be fixed before the code is merged, because if they don't you'll have lots of problems later.
Remember: The code review process is your friend. There is a reason code reviews are done, and there is a reason why code reviews are gatekeepers to merge your code, because nobody wants to deal with bad code. So do what the reviewers tell you to do and don't complain.
One note about scope creep: Push back hard on this. If what is being asked is not in the ticket, your response should be that the work for the ticket has been scoped and pointed (assuming you're using Agile/Scrum) and shouldn't be modified. If they insist on modifying it, say that the ticket will have to be re-estimated and it may throw off the scrum plans for the team, and mention this to your scrum leader and your manager. Adding stuff to tickets that wasn't originally estimated is very bad and shouldn't be done at all.