To answer this effectively, it is important to split roles, job titles, and skills. Scrum has absolutely nothing to say about job titles, so we can actually resolve that fairly quickly by saying: as long as a particular "job" does not expressly conflict with Scrum, it is "allowed" in the Scrum framework.That isn't to say that particular jobs may frequently cause disfunction. For example, a manager is "allowed" in Scrum, but if that manager is measured by his ability to drive output from the team and then the rules of Scrum are respected, hindering the manager's ability to do so, this is a recipe for disaster.
Now, Scrum describes 3 roles (actually called accountabilities in the newest revision of the guide). The Product Owner, the Scrum Master, and the Developers (think product developers, not coders). There are some rules in place about how these 3 accountabilities interact. For example, the Product Owner is accountable for ordering the backlog, while the Developers are accountable for creating the plan for the Sprint.
Both of these require certain skills and this is where someone who is used to playing the BA role may have some challenges to overcome. In many organizations, a BA is expected to work with stakeholders, understand priorities, create transparency, etc. These are clearly skills required by the PO and accountabilities of the PO. On the other hand, many BAs are also asked to figure out what work needs to be done and how. These are skills and accountabilities of the Developers. This is where having a BA can be problematic in Scrum. Now, there is a point in the Scrum Guide that says that the PO doesn't have to do the things they are accountable for. So, one could argue that a BA is simply a member of the Development team doing the things that the PO owns. This, however, gets messy in practice. Does the PO really own it? Often not. Also, there are no subteams in the Developers - does every developer have shared accountability for those things the BA does? Not in most cases.
At the end of the day, the question about BAs for most companies comes down to this: if you are trying to half-change the way you work and half stay the same, you're setting yourself up for failure. You can improve how you develop software without adopting Scrum. You can even adopt some Scrum practices if you like them. But if you say you want to practice Scrum and get all the benefits of Scrum, you kind of have to commit.