Clean architecture or ECS Architecture or both ?

Unity's own component oriented design already says "Entity Component System", which I'd say is a hint.

Clean architecture appears to me to be an architectural version of the same philosophical and practical motivations behind object oriented programming, and the subject overlaps in my view. The idea of objects is exactly that of avoiding coupling, to separate functionality into testable units, and more.

I'm not convinced that the "Clean Architecture" paradigm is as of yet fully fleshed out. The earliest references are only a few years old, though in this industry even 7 years is nearly ancient to some minds. Industrial notions, like operating systems, platforms and frameworks, change rapidly. More thoughtful, scholarly paradigms, like object oriented programming itself, takes much longer because it is a more academic and logical exercise, requiring time to collect empirical data and prove the results. Since I view "Clean Architecture" as an architectural level version of object oriented programming (which works all the way down to very small expressions of code), I'm not convinced it is actually anything new.

That said, one of the very tenets is violated at first look: Unity requires that you use its framework. That defines a dependency. Much of the beginning of any code you write in Unity begins by deriving from MonoBehaviour, which is a very deep kind of dependency. I prefer such classes be small and limited; consumers of classes external to Unity's framework for anything more than simple behavioral modifications of GameObjects. This is as much and object oriented design notion as it is an architectural notion.

I find most posting questions here are beginning their study of Unity and learn C# from that perspective as they work, so their viewpoint is entirely the opposite of your question. Indeed, many seem to think that the script is a central programming concept, without acknowledging that it is actually the class they're describing.

To think in terms of application development, of architecture and design patterns is far more appropriate when the target is ambitious, but then many of these projects are FPS, platform or other typical game designs, so they only have interest in controlling the camera, player movement, object behavior and appearance, or special effects. Most depend upon Unity's architecture and framework, seeking only to extend functionality as tutored by modifying Update, Start or creating co-routines.

With respect to unit testing, you have to consider that if the classes we're writing are derived from Unity's framework (MonoBehaviour), they can't be isolated. For unit testing to really work you should be able to build a stand alone application that incorporates the class or classes to be tested, driven by a small main program that runs the test. This shows the classes are not dependent on anything (or at least what they are dependent upon, like the STL for example), and that they work under all tested modes of operation. You can't do that with MonoBehaviour derived objects in a stand alone console application, so you have to build a Unity game for that. However, when classes comprise some service, system or complex feature (like AI, audio processing, specialized memory managers, etc), they can be written entirely independent of the Unity framework, tested, then consumed from a Unity application by incorporating the tested source.

This, too, is very much in line with the original tenets of object oriented programming. Unless you have quite an ambitious target in mind, but are making something typical of a Unity based game, the architecture is all but defined by Unity already. If, however, you consider Unity merely the rendering component of a far more ambitious application, you'd design and build the application from that viewpoint, defining specific points of attachment to the Unity design and framework, built, subsequently, as a Unity solution. In that mode you'd have a choice of architectures.