"Acceptable" depends on the team and organization norms and processes, not on the pull request.
Reading your post I thought about how often programmers talk about code "readability" and "maintainability," how we should all write our code in a way to make it easy for the next programmer to read and understand. And then I see posts like this, complaining about having to read code and understand and learn from it as part of the job.
If you view your job as a programmer as mainly writing more code rather than producing business value you will worry about things like the size of pull requests, number of meetings, learning new tools, even the waste of workplance social interaction. Any time spent not writing code gets devalued and treated like a distracting annoyance.
Reading code other people on the team wrote potentially has a lot of value. You can learn more about the overall code base beyond the parts you work on or care about. You might see novel techniques and approaches to solving problems. You might find opportunities to ask questions and collaborate (another thing programmers claim to value but actually don't do that often). Most important, reviewing, understanding, and maybe testing the work of other programmers, in the form of a pull request, directly contributes to the entire project/product in terms of business value, the value that actually matters much more than the isolated silos of code that programmers like to focus on.
I sigh when I see a big pull request too, but I remind myself that reviewing and understanding that work ultimately adds more value to the product than any code I will likely write in the time the PR review will take. I will just have less fun and derive less ego gratification from the PR review.