please substantiate the answers with valid data points, on why you feel that complexity of a project is a determining factor of sprint length
Each team chooses their own Sprint length depending on their particular context. The Scrum Guide only says that a sprint is one month or less.
So the team decides on what criteria to support their decision for choosing a particular length or another. And, yes, the complexity of the stories can be such a criteria.
Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
If your stories are big and complex, they might not fit a small sprint. So teams might choose a larger sprint length for this reason. There are no rules defined in Scrum to say that this is a good or a bad thing. The team decides.
Most teams choose two weeks. Is that based on some careful analysis or best practices? Not necessarily. Many times it's because one week feels too short, while three or four weeks seem too long.
The question now becomes: is it a good idea to use complexity of the stories as a factor in choosing the sprint length?
Again, there are no rules, but in practice, shorter sprints tend to behave better (you have shorter feedback, delivery, and inspect and adapt cycles, etc). Teams (especially inexperienced ones) tend to chose a larger sprint length because they think they have more time available to do the work. Unfortunately, a longer sprint introduces more assumptions, more risks, and more uncertainties. Experienced teams know that they don't necessarily need more time, but a way to better decompose the work so that it fits within the sprint (of whatever length they chose).
See the following links for a more in depth explanation:
No. Complexity shouldn't determine the length of a sprint. Let me point out that you actually asked two questions. The title of your question asks about complexity of stories but the body of your question asks about the complexity of the project.
The point is that, irrespective of complexity, the team ought to be able to construct stories small enough to fit into a sprint. Assuming this is a software development project, the operating model (e.g. devops / deployment pipeline and the ability of the customer to review and use the product) has more influence on sprint duration. The size of the team may also be a factor. If in doubt, for a new piece of work start with a sprint of one or two weeks and use that as a good discipline to encourage the team to write suitably sized stories.
The length of the Sprint is determined by the Scrum Teams, considering the synchronization between the Scrum Team(s) and the stakeholders. The Scrum Guide states that a Sprint is at most 1 month in duration. This means that stakeholders should synchronize with each other at least once every month.
Aside from that minimum synchronization cadence, the factors to consider include how often customers and/or end-users can review and accept product Increments, the frequency of change in the marketplace, the frequency of change in schedule or budget, and the cadences of other teams in the organization. The complexity of the items in the Product Backlog is not a factor.
Although Sprint length can be changed, it shouldn't frequently change. This lets the team fall into a regular cadence and have a much more stable concept of capacity. It also reduces decisions, preventing decision fatigue regarding when to hold the Scrum Events.