前面答主说的大部分是 LZMA/LZMA2 压缩算法的问题，但这些说法其实并不完全正确：

默认情况下的确如此，ZIP 一般默认使用 Deflate 算法，7z 一般默认使用 LZMA2 算法，LZMA2 压缩率更高，但速度慢得多，而且很吃资源。

但是， 7z 和 ZIP 不是压缩格式，而是容器格式，其中可以容纳一系列用了各式各样压缩算法压缩（或者不压缩）的条目。ZIP 一样可以用 LZMA 算法，而 7z 标准也支持 Deflate 算法，这方面两个格式本身没有本质区别。

7z 标准实际上原生支持了 Deflate64、BZip2 等算法，甚至还支持 WavPack、JPEG 等等，而第三方也提供了 Zstandard、LZ4 等算法的支持（mcmilk/7-Zip-zstd）。

实际上抛开压缩算法来看，7z 这个容器本身相对于 ZIP 也是有不少演进的：

7z 的好处说完了，现在回到题目上。7z 相比 ZIP 确实有很多改进，但是除了还有一些缺点（譬如 ZIP 可以很方便地流式处理，而 7z 解压需要随机读写实现）外，还有一个重要问题，那就是 ZIP 已经有了相当广泛的运用，可以说所有系统上几乎都有 ZIP 的实现，像 Windows 资源管理器就集成了 ZIP 支持，而 7z 的系统级支持要差得多。

除此之外，大多数语言上都有多个 ZIP 原生实现，很多语言标准库里都有一个支持 ZIP 基本功能的实现，而支持 ZIP 加密、分卷等完整功能的第三方实现也并不少见；而到了 7z 这边，大部分语言最多有一个 7zip 的 binding，很多语言还得跑去调用 7z 命令行，就算有了原生实现也基本是缺胳膊短腿（譬如 Commons Compress 包含 7z 的 Java 原生实现里，分卷压缩、加密、固实压缩等功能都仅在读取时支持）。

由于这些历史因素，ZIP 的地位在短时间内基本不可能被撼动。相比于 7z，xz 这种简单的压缩格式推广反而更顺利一些，Linux 那边已经用了很久 .tar.xz 格式了，tar 内部也有对 xz 的特殊处理。

至于 7z 有没有希望推广起来，我觉得目前主流的基于 LZMA/LZMA2 的 7z 档案恐怕很难流行，因为目前带宽越来越不值钱，LZMA/LZMA2 这种慢的离谱的压缩算法很多情况下都是得不偿失。

而我更看好的是 7z 作为容器格式，内部使用 Zstandard/LZ4 算法进行压缩的组合。更现代化的容器格式+资源占用低且快速的压缩算法，我觉得是很讨喜的搭配。