虽然我不是作者，但是可以给你一些回答。
问题1:
在脚本 require-body 为1时，你会发现返回体的 Content-Encoding 为 identify，这表明数据未被压缩，一般也不用解压。
如果确实需要压缩/解压操作， surge 文档中给出了 gzip 的解压接口 $utils.ungzip(binary<Uint8Array>)。压缩则需要更多的性能，你可以在脚本中引入第三方库，比如pako 来实现 gzip 的压缩。
brotli (br) 的解压和压缩都有很高的性能要求，在surge 的 js 环境内基本不能通过引入库来解决。
某些场景下，你可以通过修改 request.headers 中的 Accept-Encoding 字段来决定服务器返回的压缩格式。
相比于解压，压缩一般是由服务端完成，如果使用 surge 压缩需要较长的时间，在脚本中的体验很差，会导致脚本超时。
解压和压缩测试于IPhone，mac 的性能可能会强点
问题3
如果没有提供 proto文件，一般无法反序列化出可读的内容，因此建议先了解 protobuf。
问题4
Web API 应该不会完全引入，大多数的API是在脚本编辑时很少用到。如果可以，我也希望作者可以支持部分Web API，比如 TextEncoder/TextDecoder， URL
如果确实需要使用Web API，你可以去寻找对应的 Polyfill 引入到你写的脚本中。
