为什么自定义TypeScript名称空间优先使用ES2015模块语法？

Question

来自typescript-eslint docs：

自定义TypeScript模块（module foo {}）和名称空间（namespace foo {}）被认为是过时的组织TypeScript代码的方法。现在首选使用ES2015模块语法（import / export）。

来自打字稿docs

模块可以包含代码和声明。

模块还依赖于模块加载器（例如CommonJs / Require.js）或支持ES模块的运行时。模块提供了更好的代码重用性，更强的隔离性以及更好的捆绑工具支持。

还值得注意的是，对于Node.js应用程序，模块是默认模块，我们建议在现代代码中使用名称空间模块。

我对这个问题的目标是找出为什么模块语法比名称空间更可取。

这是我到目前为止一直在做的事情：

PROJECT_TYPES.d.ts

我有多个d.ts文件，在其中声明了包含我在项目源文件中使用的类型的名称空间。

declare namespace MY_NAMESPACE {
  type FOO = "FOO"
}

这样做，我可以在项目的任何源文件中执行以下操作：

someFile.ts

const foo: MY_NAMESPACE.FOO =  "FOO";

它可以工作，不需要任何import / export。

注释：

• 我正在使用d.ts文件，因为这些文件不包含任何import / export代码。
• 我使用的是declare namespace而不是namespace，因为没有关键字declare，我会收到@typescript-eslint/no-unused-vars警告。

考虑到MY_NAMESPACE是唯一的名称，应该认为这是一种不好的做法吗？在这种情况下，我是否应该在modules上使用namespaces？我不应该使用d.ts文件吗？

我的意思是，Typescript文档提到：

模块可提供更好的代码重用性，更强的隔离性以及更好的捆绑工具支持。

但是，我认为遵循上述模式不会失去任何这些好处，因为我所有的“真实”实际编译结果代码都在模块中分开。但是为什么我的类型应该只在模块中？