I am completely noob in reverse engineering, and I've just started to learn it.
Now I have this question in my mind, that does a reverse engineer use any computer architecture knowledge for doing his/her work? I mean in any field (software/hardware RE).
The question is too broad, but I'll try to answer and hope that it will help.
It depends on what exactly do you mean by computer architecture and area you applying your reverse engineering skills to. Reverse engineering Java code, Android apks, native binaries of any OS, and (for example) router or ECU firmwares are completely different things, and in some areas you will not need the data learned during the computer architecture course directly.
However the concepts learned during computer architecture course are very important for understanding how the device works, and understanding (for example) how memory access and instruction pipelines work may be critical for understanding some specific piece of code.
So in my specific case the answer is yes, I used this knowledge for reverse engineering.
A solid understanding of the fundamentals of computer architecture is very useful for a Reverse Engineer.
That said - it depends on your target. If you are reverse engineering a Java application or a web application, then clearly you won't be dealing with assembly languages and other low level concepts (though it's possible you encounter bytecode or Web Assembly). Reverse Engineering is more of a mindset than specific knowledge of computer internals.
For example, let's say you run an application and you are prompted to enter a username and password. Perhaps you want to find where in the application that logic is handled. You might do something like search for strings that are included in the login prompt and follow their references until you encounter the code that presents the prompt and handles the user input. That may lead you to find how the credentials are validated, are there any cryptographic methods used on the input, does the application make a web request to validate the credentials, etc.
The most important thing for reverse engineering isn't necessarily understanding how computer architecture works, but rather how computers and computer applications work in general. Back to the login example, clearly the user credentials have to be validated somehow, either resident on the machine or over a network. You use this knowledge to "dig deeper" and acquire an understanding of the internals of some program/machine that would otherwise be a blackbox.
Now, if you are reverse engineering compiled PE or ELF binaries, then you'll likely need to understand assembly language at some level. I often need to identify cryptographic routines within compiled binaries and without understanding assembly, the stack, the heap, system calls, control flow, and etc, I would not be able to understand the code I am analyzing and I would not have much success with whatever tools I'm using (or developing) to aid my analysis.
Good luck on your endeavor into reverse engineering!
I think generally ppl who are interested in RE are those who want to learn how things work. If your research into specific problems results in hitting a wall due to lack of computer architecture knowledge, then definitely take a course.
However, you don't have to treat education like a checklist of prerequisites that you have to achieve before becoming proficient. You could also just learn specific topics organically as you go or as they're required.
Some knowledge is perishable but that isn't the case for computer architecture, learning it will help you for many years.
Generally speaking Reverse Engineering is the reverse of engineering, so instead of making a plan and building a product, you start with a product and try to reconstruct the plan that was used for it (or something as close to as you can get).
So it's kind of a puzzle and your prior knowledge can make it easier or harder for you. I mean you can technically analyze a computer, knowing nothing about computers just having a bunch of tools and then go for it. Idk you might first disassemble the housing, then you might identify components, simply the big stuff that wires go in and out from. Then you might label and identify wires and track which components are heavily interconnected or literally "central" to the system. Or which components are actively connected to a power cable and which receive their voltage passively. You might plug-in and out some of those components to find out which ones are crucial, which are auxiliary and which are optional. Then you might track which wires run a current or which voltage is applied to which components and how that changes over time and with interaction and so on.
That way you probably learn rather intimate but also rather slow how things work within a computer. Though obviously it helps tremendously if you don't start from 0. If you already know what you're dealing with and can identify components and their functionality then that frees you up to analyze the stuff that you don't know. It also helps you to not break stuff irrepairably and it can make the black box a whole lot more transparent. In the sense that if you're aware of the moving parts, a whole new set of inputs and outputs of the system and thereby a whole different angle of attack might reveal itself to you.
So whether it's particularly useful to your problem depends on the problem, but in general any prior knowledge about a system that you can acquire is probably suitable to make it easier for you.