When I was building my backend API I used Django combined with django-rest-framework (DRF) because it was the easiest and fastest way to create what I needed.
And I haven't thought about an architecture of it.
And if I understand correctly DRF provides some kind of Model-ViewSet-Serializer pattern.
So my question is: Is making decision what architecture would look like based on framework being used wrong?
Your framework choices strongly influence the architecture your applications will have. Many of the architectural decisions have already been made by the framework for you, so trying to impose your own architecture over that would be like swimming against the current.
But this is kind of the whole point of choosing a framework. Developing a suitable architecture for your application can be tedious when you have to design and build the whole thing yourself.
In practice, unless I'm writing my own framework, I don't like to think all that much about the architecture. Architecture should be something that's just a part of the fabric of your application, not an end in its own right, and if you use a framework that you like that does all of the architectural heavy-lifting for you, so much the better. It means that you spend more time developing actual functionality and less time putting in plumbing.
If you're going to go this route, you have to think carefully about your framework choices and how each one fulfills its role of helping you build your application. But choosing a framework because it is a "quick and dirty" way to get an application working is a perfectly valid choice. It all depends on what your actual needs are.
The answer to your question from the title depends on the definition of "software architecture". One popular definition is: the design decisions which are costly to change at a later point time (at least not without a complete rewrite). So choosing a framework like DRF is an architectural decision.
However, from your question text, I guess you have a much narrower idea of "architecture" in mind, like which layers your program should have, which responsibilities those layers should have, and maybe which technologies are available for each layer. That is the part of a system's architecture for which Robert Harvers answer applies. Here it depends heavily on the specific framework how much freedom it gives you in defining your own layers, and how much it predefines for you.
If it is good or bad to rely on such predefined layer decisions depends mainly on the amount of evolvability you will need for your system. If you expect future requirements which may easily hit the architectural limits of the framework, then the choice was probably a poor one. If you think such requirements are unlikely to arrive over the lifetime of your program, then the choice is fine.
Often, this leads to a dilemma: one picks an "rapid-application-development" framework "to get things done as quickly as possible" (since time-to-market is more important than anything else at the beginning). Later, new requirements show up and cannot be easily integrated into the system because of the framework's limitations. Then it is probably a good idea to throw away the initial version, pick a less limited framework, which may (or may not) include a different programming language, and reimplement the system again from scratch. But when you are in such a situation, better do not to wait too long, otherwise a rewrite becomes too costly and you will be stuck on the initial architecture.
