How to design your code architecture in unity?

I've not been programming Unity long, though I've run into many of the same frustrations. It seems like the Unity library is constructed to facilitate a lot of cowboy coding practices, with little or no real encapsulation. The tutorials also tend to have everything
as a MonoBehavior or ScriptableObject, where it is often entirely possible to sequester code into a standard C# object without involving UnityEngine, which can help to keep things cleaner.

It seems like the tutorials also use SendMessage() where it isn't really needed - they could have precached a reference to the object/component they're trying to interact with, and use that directly. And it seems like they pretty much never use packages at
all, everything shares one big happy namespace.

I understand the general mindset seems to be "Unity for Dummies", making it seem as straightforward as possible to write something that will operate correctly, with no concern for code quality, reusability, maintainability, testability, etc. If you follow the
tutorials, and lean on the UnityEngine classes, you'll wind up with a tangled mess of code before you know it. Keeping code clean and well-organized is a struggle you have to put more effort into with Unity than you might with other platforms/frameworks.

I have found a few things to be very helpful:

Minimize your MonoBehaviors. If you can make it a plain C# class, do that. If you can encapsulate functionality into a plain class and reference that from your MonoBehavior, do that. Try to avoid using UnityEngine in your plain C# classes when you can.

Singleton MonoBehaviors can be achieved with a static singleton reference and a check in your Start method: if the static singleton reference is null, set to self, if it's not null, throw an Exception. The only way this would happen is if you have more than
one instance in your Scene, so an exception will tell you (the developer) that you've done something you shouldn't have.

When planning your architecture, try to decide ahead of time what you want to be editable in the Unity inspector. Those fields will need to be part of a MonoBehavior or ScriptableObject. Everything else is fair game to place a MB/SO or into a plain C# class.

Likewise, any class that has to run code during a *Update or On* call should generally go into a MB, though you can also define this code in a normal class and call it from MB. The thing to note here is, if you end up having to reference Unity functionality
like GameObject from your code anyway, there's less point in encapsulating it in a normal C# class.

Subclassing/inheritance seem to give Unity a migraine - or, at least, using them with Unity gives me a migraine. Any time I try to work with an object hierarchy that I've created with MonoBehavior or ScriptableObject at the top, I wind up wanting to shoot myself.
But that may just be due to lack of experience with Unity and/or C#.

I would agree that, in general, the tutorials seem to just cram code in wherever it's most convenient for expository purposes, because nobody has to maintain that tutorial code later. It's also hard to provide general guidelines as every game is different;
for example, my current project encapsulates a lot of input handling into it's HUD class, but that might not be appropriate for your game; you might want to encapsulate it into a Controller class or some such. A point-and-click UI will be organized in code
very differently compared to a WASD-style shooter, as a matter of course.