This is a very naive view "If I can do in Y time, why can't ?".
Any large company has a tens, hundreds, or even thousands of different teams who may own a system with some data that identifies you as a customer. Presumably, they're on the hook for serving you (the customer) all of this data when you ask for it. Honestly, I'd hate to be a legal counsel at a company having to sift through every attribute/data column trying to figure out what we "have" to return vs. what we can probably keep hidden as a trade secret, but I digress.
Anyway, there's no guarantee that even half of the systems storing this data were designed with GDPR (or whatever privacy-related) compliance in mind.
Consider a system that's storing nested JSON blobs with customer-identifying data several layers deep. You happen to be on a team that owns this mission critical system. Your legal department gets you to prioritize some dev work to build a system to quickly extract this data.
You'll (probably) do it in the most cost effective manner – it might mean rearchitecting your system if the cost of extracting that data is very high. It could be that you have the tools to extract this data very quickly and so you just need to plug and play. Or there's at least one more scenario where such an operation is so expensive (and impacting on your main business function) that you accumulate a bunch of requests (i.e. 30 day window) and run some ETL to get all the customer data and respond on the compliance requests. So with that approach it's definitely not a real-time or near real-time response.
And my example scenarios here are actually pretty simplistic for a large company. Imagine the scenarios where you have N customer records with some loose notion of an evolving schema over the years. You're not even sure how to query that data or transform it... or your automation works 98% of the time to pull the customer data but 2% of the time it fails, and so you have to time (legally) to manually have an engineer fix that edge case (depending on how expensive that work is) or the engineer manually goes and pulls your data, accounting for whatever edge case that was discovered.
The more data you store about a customer, the "harder" this would get.
I would probably use data retention policies to drop as much data as I can, although I'm sure at a large company, your business customers push back: "Oh we've never had to use that data set, but we want you to keep it because we might use it to build features for some new ML model in the future or to solve other problem ".