The iCloud Photo Library doesn’t have any public APIs that I know of. You simply can’t recreate the Photos app completely, regardless of app sizes. Apple values deep integration into the system more than it values giving third party developers a fair chance at cloning their app.
I'd bet my money that you can roll your own iCloud-esque Photo Library and it still won't be near the 100MB territory if you just use native libraries for the UI. Everything you'd have to do from scratch: cloud auth, encryption, syncing, compression, transcoding, etc. is all at most a few MBs combined, not to mention that all of these except cloud auth are already in the built-in libraries on iOS that any app can freely use.
What the apps here are doing is shipping whole (UI) frameworks and tons of old code and assets that aren't really used anymore but nobody dares to remove.
You can access iCloud from an iOS app, it has its own public framework called CloudKit, so you could create your own version of it. If you don't like that example Chrome and Edge are both forced to use WebKit on iOS but are still much larger so.
If the point of a Google Photos app is to access / back up your photos via Google Photos (web), then it seems rather dubious that making API calls to a cloud server is an endeavour that takes hundreds of megabytes of code and resources.
If, rather more accurately, the point of a Google Photos app is to provide a photo editor and various other photo-adjacent functionality coincidentally including the ability to back up photos to Google's servers, then again that raises the question of why Apple's equivalent app is so much smaller. Are there image-related system frameworks that Google cannot use that Apple is using? Then sure, feel free to count them in Apple Photos' "true" size. But if Google simply won't use them then IMO it's fair to ask if the size of what they're shipping is worth it.
