正如其他人所提到的，这是权衡和拥有正确知识的问题。
您可能要考虑的唯一陷阱是：您在问题中提到，您将Web视为具有“跨平台”优势。但是真的吗？可以这样考虑：如果为桌面开发某些东西，则需要定义平台列表及其支持需求。
毫无疑问，对于网络来说都是一样的。即使它已经比以前简单得多，但如果您设计一个广泛的公共应用程序，则必须处理每个Web浏览器的所有可能版本。而且，如果它更像是企业应用程序，请做好准备，并准备非常精确地起草支持的浏览器平台要求。
如果您构建了重要的东西，别以为您会在这里和那里避免针对特定平台的黑客攻击。
然后是有趣的部分。什么是最好的？像Chrome一样定期定期透明更新的浏览器？还是推出安全性的功能每个石器时代（例如IE）仅每月更新一次主要功能？答案并不像您想象的那么明显，因为其中一些频繁的“透明”更新可能会破坏您的代码，因此您将需要遵循并迅速做出反应。或者在开发和测试时关注beta和dev的预发布版本。对于所有的浏览器，您都愚蠢地说要支持（祝您好运）。
哦，我们不要忘记UI注意事项。您还面临决定的喜悦，你是否希望有一个一致的用户界面横跨所有目标平台，或一致的用户界面与每个主机的目标平台。看到所有可以在网页上查看的小按钮了吗？您是否希望它们在任何地方都完全相同，还是要与用户使用的环境集成在一起？当然，对于其他开发模型来说，这个问题并不是新问题，而是存在的，但它似乎在这里更重要，它取决于您所针对的用户类型以及他们的期望。公共最终用户倾向于希望您与他们的平台集成-但仍然希望您“哇！” 它们带有奇特的东西-而企业用户则需要类似于桌面应用程序的东西。移动平台为这一切带来了新的维度。
对于最后两段，通常的想法是有时将预配置的Web浏览器与安装程序打包在一起，然后将其连接到Web应用程序（本地托管或在Web上）。很棒是因为您可以控制更新频率，并且可以“冻结”状态，并且确切知道要支持和测试的内容。另外，您还可以添加一些很酷的内容，例如专用的用户扩展。例如，将“冻结的” Chromium与您开发的小型Chrome扩展程序包装在一起，可以使不同类型的用户更轻松地使用网络应用，这非常好。另一方面，如果您由于冻结发布周期而发生安全漏洞，则现在要负责，并且您的应用不会受益于速度提高（如果有）。
像很多东西一样，它是一把双刃斧。
注意：我对网络有强烈的偏见，因为它基本上是一大堆半成熟的技术（在这里我很有礼貌），直到OSI层，在这些层上，我们不断添加废话，隐藏了真正没有解决的问题或修复它们。
话虽这么说，我赞成网络作为平台的无处不在。我认为您公司的举动（可能）是正确的。显然，这取决于目标市场和目标平台。如果您想将某些东西作为服务公开，那么您可能会很高兴（尽管也没有必要）。如果您不这样做，那么可能没有太多原因。
嗯，现在，随着现有操作系统的轻量级变体不断涌现用于移动环境（上网本，智能手机，PDA，平板电脑，电子书等），并希望使用轻量级嵌入式浏览器，将来会出现有趣的发展。 ..但它们都有所有新的UI渲染故障。
关于基于插件的技术...我会说远离它们。它们将增强您应用的功能，但会限制其市场渗透率。在某些情况下，在跨平台支持方面，您会发现它是一个加号，直到新平台突然拒绝支持它们为止。Web Standard之所以在这里是有原因的（请注意，不要对HTMl5中的所有内容都太过兴奋，否则它可能会炸掉您的脸）。
编辑：其他要考虑的事情...
招募
这是非常难找到懂行的Web开发人员。您可能会认为有很多人，但是他们却迷失在一大批无能的人之中，他们认为设法编写了700行JavaScript / ECMAScript以其形式实现一些验证是最终的选择以及所有可以通过高级技能实现的目标。
我不是在开玩笑，最近，所有网络开发访谈中的第一个问题是如何声明变量，然后使用之间是否有区别var（取决于它们的回答方式）。令人沮丧。我发现找到普通或高级的Web开发人员要比找到普通或高级的桌面开发人员困难得多。
知觉
当您说“我是网络开发人员”时，没有人会认真考虑您。它是针对程序员，开发人员的子类的，不是吗？您会在远处忽略和嘲笑的人，去喝咖啡时不会加入。:)
这显然是不正确的，但是可以归结为您为主要由您管理的环境进行开发的事实。浏览器会修正您的错误标记，错误样式，甚至会更正其中一些错误脚本，并根据需要为您进行优化。而且，如果您是Web开发人员，人们不会以为您对底层编程有所了解，因此您必须是一个完整的白痴，对吗？
然后他们意识到ECMAScript有多么疯狂的复杂性，但是他们拒绝评论他们的观点。因为它是网络。我们本质上并不喜欢它，我们只是喜欢它使我们能够做的事情。