我应该只使用它而不是旧类吗？
不，不需要排除旧类。旧的 java.util.Date/.Calendar 的工作方式相同，没有改变。 未已被弃用。
您可以混合和匹配所有三个框架（旧类、Joda-Time 和 java.time）。请注意一些相同或相似的类名——注意你的import 语句！
请参阅教程，Legacy Date-Time Code。
此外，ThreeTen-Extra 项目扩展了 java.time 的附加功能。 “ThreeTen”指的是定义 java.time 的JSR 310。
我是否应该在我发现旧类的地方替换它们的现有用法，因为新的东西要好得多？
如果旧代码按预期工作，那么现在无需更改。
如果您担心旧代码可能无法正确处理时区或一直想要进行更多本地化，您可能希望使用 java.time 重新编写它们。即便如此，请记住您可以轻松地在 j.u.Date 和 Instant 之间进行转换。因此，您可以将业务逻辑保留为 j.u.Date/.Calendar 并仅更改用户演示代码以使用 java.time。
我是否应该避免同时使用 java.util.Calendar、java.util.Date、java.sql.Date 和 java.text.DateFormat 来支持新 API，或者是否存在旧类仍然存在的用例比较好？
您将需要旧类与旧代码和需要旧类型的库进行互操作。同样，旧的类没有被弃用，也不会消失。鉴于它们的广泛使用以及 Java 团队的首要任务是保持向后兼容性，它们可能永远不会消失。
新的 java.time 类 要好得多，这就是添加它们的原因。而且它们更合乎逻辑且更易于使用。所以是的，学习如何使用它们将是有益和愉快的。但不紧急。在紧要关头，以您习惯的旧方式编写代码。当您有时间学习 (Tutorial) 并进行额外测试时，请开始使用新课程。
新手程序员当然应该把学习重点放在 java.time 上。
由于新的 Date API 类似于 Java 8 流 API 替换 Guava FluentIterable，Joda Time API 是否已经过时？
Joda-Time 是 java.time 的灵感来源。同一个人发明了两者。他们打算让 java.time 成为他们对 Joda-Time 的“2.0”重新发明，如果他们知道他们现在所知道的，他们会做什么。他们说 Joda-Time 用户应该过渡到 java.time。
也就是说，Joda-Time 不会消失。它仍在工作中，仍然通过错误修复和新的tz 时区数据进行更新。对于没有其他像样的日期时间库（据我所知）的大型 Android 社区来说，这非常很重要。因此，您可以继续依赖 Joda-Time，无需迫切删除旧代码，但不会期望新功能或增强功能。
Joda-Time 已久经考验，而 java.time 有一些小错误和问题需要解决。 Joda-Time 和 java.time 各有特色。所以就个人而言，我混合搭配以最适合。我在涉足 java.time 的同时依赖 Joda-Time。
计划最终过渡到 java.time，但不要着急，不要恐慌。