To your overall question, while Scrum can be applied in most projects, it is not necessarily the best approach for some projects. That said, it is well suited to complex problems that require discovery of the solution and adaptation to new information. Your project sounds like exactly the kind of project Scrum was designed to tackle. However, you raise some important points and I'll try to address them:
1) A product owner needs to understand the domain they are working in at a level that they can intelligently identify and discuss the key problems that need to be solved in order to create value. For example, the PO for the large hadron collider better know their quantum physics. It is completely possible that you have the wrong PO for your work. It is worth noting, however, that they do not need to understand how to solve the problem to be effective - that's the team's job. In fact, sometimes it's better if they don't so they can get out of the team's way.
2) While product backlog items can come from anyone, the PO must understand them enough to speak to their value and be able to prioritize. Are your backlog items expressions of problems to be solved or tasks in the solution. If the former, then again you may want to look at a different PO. If the latter, you might have the wrong items in your backlog.
3) First, you don't need to use user stories. However, you do have some person or group of people who benefit from your work. Your backlog items should each provide value to them. If a product provides no value to anyone, you should cancel it. (I am, of course, being hyperbolic. I've never actually encountered a project that provided no value to anyone)
4) Relative estimation is designed to be able to handle uncertainty or unknowns and helps in most projects. However, some projects have so much uncertainty as to make estimations useless. Luckily, Scrum does not require them. A recommendation I would make is that if you don't use estimations, use time boxes. A time box sets the amount of time to work on something before coming back to the group to see if it is worth continuing to pour time into or if something else is more important.
5) This is a common challenge. The solution is simple, but takes practice to get good at. The solution is to either a) break down the problem into smaller problems or b) run an experiment to gain validated learning rather than long investigative learning processes. The first is used in cases where the investigation cycle is long due to simply trying to investigate a lot of things. The second is used when the investigation cycle is long due to many complicating factors needing to be accounted for in complex problems. Of course, it is way easier to type this paragraph than to do it, so don't feel bad if you run into some problems you don't know how to tackle in a sprint.
6) Who wants higher performance, how much do they want and how will it impact them? That is who you have in your review. Your problem space sounds very narrow, so I would not be surprised to find out that your reviews are very straight-forward.