a few websites that when a page is requested from their server, they grab the asset files from their cdn, process them (compress, minify, etc.) cache the results on their server and then send them to the user requesting the page.
OK, assuming you have
www.company.com on your own servers, and you also have a CDN service provided by another company. Do you mean pull data from storage on the CDN and over to the server park running
www.company.com, and then serving it from there to the end users?
If that's what you mean, it makes no sense, and appears to be a mistake. It could make sense for some forms of "cloud file storage", such as Amazon S3. But Amazon S3 is not a CDN, it's a highly scalable file storage, which is not distributed to POPs around the world as a CDN is. (If you want a CDN in the Amazon family of offerings, then you want Amazon CloudFront.)
Perhaps you mean the other way around, you have
www.company.com on your own servers, and you server up assets to your CDN. Your CDN then minifies & HTTP compresses them, and serves them compressed to the end user? That's normal, but it's just a question of what is easier to configure. Some people/companies can't seem to spare the effort to configure their own web servers, so they ask the CDN to handle this instead. (Which BTW is only a partial solution, as only the 'static' CSS and JS etc is then served optimally -- the HTML typically doesn't pass over the CDN.)
From what I understand that CDNs are meant to physically cache your static files in multiple regions closer to your users.
Yes, that's correct. "Closer" is short-hand for "with less network latency" in this context.