我猜assert没有被更多地使用的主要原因是没有人使用Python的“优化”模式。
Assert是一个很好的工具来检测编程错误，以保护自己免受意外情况的影响，但所有这些错误检查都是有代价的。在C/C++等编译语言中，这并不重要，因为Assert只在调试版本中启用，并完全从发布版本中删除。
另一方面，在Python中，debug 和 release 模式之间没有严格的区别。解释器具有“优化标志”（-O），但目前这并没有实际优化字节码，而只是删除Assert。
因此，大多数Python用户只是忽略-O标志，并在“正常模式”下运行他们的脚本，这是一种调试模式，因为Assert被启用，__debug__是True，但被认为是“生产就绪”。
也许切换逻辑会更明智，即默认为“优化”，只在显式调试模式（）下启用Assert，但我猜这会让很多用户感到困惑，我怀疑我们是否会看到这样的变化。
（（）这就是Java VM的实现方式，通过一个-ea（启用Assert）开关。

我想到几个原因...

不是主要功能

许多程序员，让我们不要陷入基本原理的泥潭，不尊重任何不是程序倒数第二个功能的直接参与者。Assert语句旨在调试和测试，因此，他们负担不起的奢侈品。

单元测试

assert语句的出现早于单元测试的兴起。虽然assert语句仍然有其用途，但单元测试现在被广泛用于构建一个敌对的环境，以打击子例程及其系统。在这种情况下，assert语句开始感觉像枪战中的刀子。

提高行业对测试的尊重

Assert语句最适合作为最后一道防线。它在C语言统治世界的时候上升到了崇高和不可触及的高度，作为实现新发明的“防御性编程”的一种伟大方式;它在灾难性灾难摇摇欲坠的时刻识别和捕获灾难性灾难。这是在测试的价值得到广泛认可和尊重之前，灾难也更加常见。
今天，这是闻所未闻的，对于任何严重的商业软件发布没有某种形式的测试。测试是认真对待，并已发展成为一个巨大的领域。有测试专业人员和质量保证部门与大检查清单和正式的标志-在这种情况下，程序员倾向于不去理会Assert，因为他们相信他们的代码将受到如此多的令人厌倦的测试，这并不是说他们是对的，但是如果懒惰编程的责任可以转移到QA部门，为什么不呢？

我不是这些项目的作者，所以这只是我根据自己的经验做出的猜测，如果不直接询问这些项目中的人，你不会得到一个具体的答案。
Assert是一个很好的工具，当你在你自己的应用程序中进行调试时。正如你提供的链接中所述，然而，当应用程序能够预测并从一个状态中恢复时，使用条件语句会更好。我没有使用过zope，但是在Twisted和Django中，他们的应用程序能够从你代码中的许多错误中恢复并继续。在某种意义上，它们已经“编译掉"Assert，因为它们实际上可以处理它们。
与此相关的另一个原因是，通常使用外部库的应用程序可能需要进行错误处理。如果库只是使用Assert，那么无论错误是什么，它都会引发AssertionError。通过条件，库实际上可以抛出有用的错误，这些错误可以被应用程序捕获和处理。

根据我的经验，assert主要用于程序的开发阶段-检查用户定义的输入。assert并不是真正需要捕获编程错误。Python本身非常能够捕获真正的编程错误，如ZeroDivisionError, TypeError左右。

不使用assert，因为它需要更多的时间来运行代码，也就是说，我们必须牺牲速度