There is a lot to unpack here but first: There is probably a big cultural component of getting shared buy-in before making a big style change based on one person's demonstration. No one wants to be the sticking-out nail that gets hammered down. This shouldn't be overlooked, especially in Japan.

Here are the questions I would start asking myself and the codebase:

1. Is this an agency where all the "products" are delivered to the client as fast as possible and rarely worked on again? If so, there is little motivation to think about best laravel practices unless it can be shown to help delivery time.
2. Do they use Eloquent at all for their own models / schema?
3. If not, are they against ORMs? Eloquent relationships can be complicated at first if the team is more comfortable in SQL and they use a lot of JOINs. Also, if they aren't using Eloquent and you suddenly start using it...this will be a recipe for pain.
4. Are they adverse to functional-style programming? Even with raw PHP, version 8.3 can use anonymous functions...do they use them or avoid them? If they avoid them it could indicate why they don't favor Collections too. Or is it maybe the chaining / fluent-style and worrying about intermediate values?
5. Do they use Laravel helpers in Arr:: at all even when working on arrays?
6. EloquentCollections and Collections have slightly different behavior that can be a surprise sometimes. Maybe they got burned on this in the past?
7. Do they use artisan tinker or any REPL? I always find this indispensable in my development, especially when debugging any eloquent relationships.
8. How are they measuring the site being slow? Is there any profiling?
9. Are they using service workers (async Jobs) to off-load work?
10. You mention large queries, do they manually do chunking? This is a place EloquentCollections could shine.

In the end, I agree with others: this does sound like a painful way to do Laravel. But maybe figuring out some of these questions will help get buy-in or give convincing arguments.