Complementing Evgeny's answer with a few more examples.
What you mean by build size may matter a bit:
if it is the size of the artifact(s) being built (each one individually or their combined size) - that could matter in artifact storing or use/deployment operations if those operations have size limits and they are exceeded. For example Google App Engine apps has such deployment limits, if reached deployments would fail, see Error when deploying to Google App Engine.
if it is the size of the workspace in which you perform the build it may matter from the workspace management perspective. Even 2G may be significant - for example if you're building in a RAM filesystem on a machine with not a lot of RAM. But some builds could a lot bigger - I had to deal with 500G+ workspaces (when most of my server disks were below 1T).
If the build is part of your CI/CD pipeline then the larger the build size the longer will the pipeline execution time be (performing the actual build and, if applicable, archiving, deploying for testing, analyzing in case of failure, cleaning up, etc.) - the slower/riskier/costlier your overall development may be.
If you hit a hard limit you'll have to get creative to work around it (not always simple/possible). If it's just a performance/cost hit you also have the option of accepting and living with it and/or addressing it partially/gradually.
It may be worthy to distinguish between:
- bloated builds - when size is unnecessarily increased - fixing the problem is usually possible by dropping unnecessary parts
- the cases in which the content of the build itself is what's really needed - the size doesn't matter as much - it is needed, the only way to address may be by sacrificing some functionality