TL;DR
example.comというドメインを持っているとしたら、必ずhttps://www.example.com/を正式なURLにしましょう。https://example.com/へのアクセスは、ロードバランサを使用してhttps://www.example.com/へ転送してください。Google Chromeではwwwは省略して表示され、Firefoxではwwwは薄く表示されます。Google、AmazonやAppleはこの戦略を使用しています。
マーケティング上の理由でwwwを省略しようとするのは時代遅れです。
Apexドメインの問題
ルートドメインにはドメインの正当性を示すためにSOA (Start Of Authority) リソースレコードと NS (Name Server) リソースレコードが登録されるようインターネット標準で決まっています。一方、ドメインの転送を行う際に指定するCNAME (Canonical NAME) リソースレコードは、他のリソースレコードと同じドメインに設定してはいけないとインターネット標準で決まっています。この制約のため、ルートドメインは別名としてApexドメインやネイキッドドメインと呼ばれて特別扱いされています。どうして特別扱いされているかというと、トラフィックをCDN (Content Delivery Network) に転送する際は、DNSに組み込まれている負荷分散の機構を十分に活用するために、通常はCNAMEリソースレコードを使用するのですが、Apexドメインでは、前述した制約によりCNAMEリソースレコードを設定することができないからです。
以上のことから、Apexドメインは正式なURLとして使用するのには適していないことが分かります。今はIPアドレスをAリソースレコードに指定していて問題なくても、将来CDNに移行しようとするときに必ず困ります。
回避策とその問題
このApexドメインの制約を回避するために、ALIAS擬似レコードをサポートしているDNSベンダーが存在します（https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html ）。ALIAS擬似レコードは、DNSサーバーが転送先のIPアドレスを調べて、あたかもAリソースレコードが登録されているかのように振る舞います。結果的にCNAMEリソースレコードを使用しないので前節の問題は回避できるというわけです。
この説明を聞くとこれで問題解決じゃんと思うかもしれません。しかしALIAS擬似レコードには大きく2つの問題があります。
一つ目は、IETF (Internet Engineering Task Force) による標準化がなされていないという点です。ドメインのシステムの中でALIAS擬似レコードが将来にわたって正しく動作することは誰も保証していないし、保証できないということです。過去にANAMEレコードが議論されていたようですが、今となっては誰も話題に挙げていないようなのでALIAS擬似レコードが標準に入る可能性は限りなく低いです。
二つ目は、DNSに組み込まれている負荷分散の機構をダメにしてしまう点です。ホストと権威ゾーンの間に余計なサーバーが介入するので、ロケーションに応じて最も近いホストのIPアドレスを返すといったことができなくなってしまいます。AWSの場合は、AWS内部のサービスをALIAS擬似レコードが指している場合はうまく負荷分散できるようですが、別のベンダーのサービスが入ってくると全てが狂ってしまいます。このALIAS擬似レコードの負荷分散の方式が標準化されていないことが原因でこのようなことが起こってしまいます。
結論
IETFが定めた標準の範囲でうまくやるべきです。マーケティングのために技術的標準から外れた設定は行うべきではありません。本当にマーケティング上で重要なら標準の方が変わるはずです。変わっていないということは、そこには価値はないということです。