Doesn't really matter after compression unless the bulk of your code can be culled from the end product. Tbh the largest business value this has is slowing down people trying to use your internal APIs.
+--------------------------+---------+---------+---------+--------+
| Library | Size | gzip -1 | gzip -9 | brotli |
+--------------------------+---------+---------+---------+--------+
| bootstrap.css | 280813 | 47312 | 33109 | 24533 |
| bootstrap.min.css | 232948 | 42003 | 30776 | 22695 |
| react.development.js | 87574 | 28733 | 23513 | 19818 |
| react.development.min.js | 25612 | 10217 | 9224 | 8052 |
| tailwind-2.2.19.css | 3642321 | 376787 | 304100 | 82049 |
| tailwind-2.2.19.min.css | 2934019 | 354063 | 294632 | 72803 |
| vue.global.js | 476920 | 134655 | 105130 | 87121 |
| vue.global.min.js | 167898 | 74769 | 65582 | 57922 |
+--------------------------+---------+---------+---------+--------+
Edit: something important to note: some frameworks (e.g. React) have lots of comments on their un-minified versions, that are removed when minified. That affects their size greatly.Are you telling us your code doesn't? :-)
Nah, in a more serious note, to properly compare the impact of minification, I should remove the comments from the unminified (maxified?) version first. :)
In the example given:
Original - 147 KB
Minified - 123 KB (83%)
Gzipped - 22 KB (15%)
Both - 20KB (14%)
Compression is waaay more effective, so if you have to pick one, go with compressing. Is having readable source code worth the other 2KB? That's up to you. Source maps can do the same thing with less, though. Also, modern devtools have ways of de-minification (if you don't mind all the mangled variable names).
At least with jQuery, it seems that minification matters considerably.