アーキテクチャーの必要性

アーキテクチャの必要性については、1つの指標として、マーチン・ファウラー先生の内部品質の影響を可視化したグラフが役立つかもしれません。
https://bliki-ja.github.io/IsHighQualitySoftwareWorthTheCost/

このグラフでは、内部品質への投資に対する生産性のリターンが1か月以内に損益分岐点に達することを表しています。

大規模・小規模に関わらず、1か月以上続くサービスの開発を想定しているのであれば、なにかしらアーキテクチャを導入した方が良さそうに思います。

　プログラミングにおいて、必ず使わなければならないということもありませんし、これらを完璧にマスターしないといけないというわけではないと思います。現に私もすべてを知っているわけではありません。
　しかし助言をされたということは、おそらくですがその勉強をある程度していたほうが良いということだと思うので、必要な理由について解説をさせていただきます。
　たとえばMVVMはアプリ開発において、アプリの画面の状態を管理するのによく使われるモデルです。具体的には、ユーザーの操作を受けてAPIから取得したデータの流れやユーザーが入力したデータの流れ、画面に表示するデータなどを管理します。世の中にはそれに特化したライブラリがたくさん存在しますが、それを使うためにはそのデータの流れを少し知っておくくらいの基礎知識は必要だと思います。

　どのようなクラスを設計しているかはわかりませんが、データを保持するモデルとなるクラスならば、今後のプログラムのコアとなる部分なのでとても大切だと思います。
　考えなくてはいけないことしては、どのようなデータをどんな形式（使いやすい形式）で保持するかや、やみくもに変更してはいけない変数のカプセル化、変数のゲッター・セッターなどがあります。

　コアクラスの定義はとても重要なのでよく考えて設計することをお勧めします。
ちなみに、何を作られる予定ですか？

必要か否か、という問いであれば自分の経験上「必須」だと思っています。

ただ、設計（≒アーキテクチャ）というのがなぜ存在しているのか、というのを知っておくことは重要かなと思います。

やや逆説的ではありますが、仮に、あなたが神にも等しい記憶力とコーディング力があり、一瞬ですべてを変更することが可能であるならば設計は必要ありません。
しかし人間の能力的にこれを実現することは不可能です。

設計、というとやや大仰な話に聞こえてしまいますが、なんのことはない、整理整頓しようね、という話なんですね。

例えば本棚の整理をしていたとしましょう。あとで読まないならただ詰め込むだけでいいですが、あとで本を取り出して読む場合、少なくともジャンルごとだったり著者ごとだったりで整理するはずです。
またシリーズものであれば連番で閉まっておくのが通常ですよね。

プログラムの設計というのは、極論で言ってしまえばこうした「あとからなにかするときに楽にする方法」と言うことができると思います。
そう考えると、たとえどんな小規模なものでも必要であることがイメージできるかと思います。

ここでひとつ注意点があります。
例えば上記の本棚の例えで説明すると、小さな本棚や、机の一部に作るブックスタンドであればせいぜい、順番通り、くらいのまとめかたになるかと思います。

なにが言いたいかと言うと、設計とは、プログラムの規模に応じて変化するものだ、ということです。
小規模なプログラムなのに大規模なプログラムと同じような設計をすれば、ただコードが増えるだけで設計の恩恵は少なくなってしまうでしょう。

なので、「ここはあとから楽をしたいな」という点に絞って設計をすればいいのです。

事実、設計手法を学んできましたが、モック作成などではがっつり設計することはありません。局所的に（あとから変更を求められそうなところに）設計を導入しています。