First, pega doesn't generally serve unauthenticated content...you must have a requestor session and be authenticated. Even if authenticated as a guest this would mean every anonymous user would be consuming heap for their requestor session which would be a scalability issue on a site where there are many users but few who actually interact with the chatbot/chat widget.
Third, public access to the Pega server is often restricted via WAF or reverse proxy for security purposes. For example you might use SiteMinder to ensure that only customers logged in to the website are allowed to contact the Pega server. This would only impact certain customer scenarios but there at least needs to be an option to serve this content from another source.
Fourth, if the static content was served by the Pega server this would mean the server would need to be sized to handle loading of static content of many anonymous users. Imagine a website where 10,000 users visit and 10 request a chatbot session. The Pega app servers can be sized to handle 10 concurrent users. If the widget static content is served from that app server, it will need significantly larger resources (CPU, memory, network) to handle the 10,000 users.
Finally, you actually could serve this content from the Pega app server. Any application server could have an additional application/servlet installed to serve static content off the filesystem instead of from the Pega database. As far as I know this isn't a service offered by Pega Cloud but could be implemented on any customer-owned environment. However a standard best practice for performance is to host static content on an edge server, a server tuned for fast static content, or a CDN. It would only make sense to serve static content from the Pega app server in a dev/test or a low volume environment where sizing is less of a concern.