Tech stack and managerial considerations (non-developers)
If you're a developer, then choosing a tech stack to use is probably going to come down to what you are most familiar with. For non-developers, that isn't going to be as relevant per, since if you are hiring a developer then it's just a case of them being competent at whatever stack they are working with.
Even if you are not a developer, you need to have at least some understanding of the tech stack and infrastructure your website uses. There are many reasons for this, explained below.
You can't manage a hired developer if you don't understand what they are doing
This isn't just bad for you, but for the developer too. Developer nightmares are full of clients who don't have any idea about the work being done, think some specific work is good or bad due to misinformed ideas, totally misunderstand the progress or purpose of a particular piece of code...
It's not just about, for example, being able to "measure progress". It's also that the developer will be unable to properly advise you on technical implementation matters that are relevant to your website, making it difficult or impossible for you to make good decisions, and simultanously making it harder for the developer to do what you want them to do as they will have less clear instructions.
On the other side, if a developer isn't competent and is writing bad code, a lack of technical understanding makes it impossible for you as the manager to be aware of this. Website performance, for example, is not necessarily an indication of developer competence, and neither are things like poorly designed interfaces or 'janky' webpages. These can often be due to bad managerial decisions (e.g. not spending enough on sufficiently powerful servers), or because of bad instructions to developers that effectively ask for bad code to be written.
As a result, you won't be able to evaluate what your developer/s are doing, and will likely have to rely mostly on 'trust', which is not good for any party in the equation.
It's difficult to grasp the scale of website issues without underlying tech knowledge
Suppose a website is slow to load, whether on a particular page or all pages. Without a proper knowledge of the different parts of your website that contribute to loading times, it's difficult to properly understand "why" the website loads slowly, which part of the system is slow, or what a developer could do about it (or even if it is something a developer can fix).
That also makes it harder to meaningfully make use of user feedback, because doing so means translating user feedback into development tasks, and that's hard to do without knowing the tech stack you are using.
Not understanding the tech stack can cause security vulnerabilities and horrendous inefficiency
Naturally, a competent developer is going to be aware of potential security vulnerabilities that can happen in applications, and is not going to deliberately overlook them. However, if you are managing a developer, this can still cause several problems to arise:
You are the boss, and ultimately have the final say
If you instruct a developer to implement something that will cause security risks, they will warn you about this, but you are ultimately still their boss and they cannot "refuse" to do it if you do not grasp the implications of their warning.
The developer can't always know what you don't know
In situations where a "potential" risk may exist, a developer might assume you already understand the risk or that it is implied that you do, meaning you may introduce a risk you didn't think was there. The same applies with code that can be done "quickly", but that will cause efficiency or project problems later down the line.
Unrealistic deadlines can lead to expensive bug fixing and security vulnerabilities
If a developer is given deadlines that are not reasonable - much more likely when the manager does not understand the tech issues in play, or because of a perceived need to please site users - it is likely they will have to cut corners attempting to meet that deadline, which not only has the risk to cause security vulnerabilities but frequently causes buggy code. This tends to cost more in fixing the bugs later than it would have costed to do the code properly the first time around.