Neither is always better, and both have their strengths.
The idea of scoring higher marks as a criteria for better is going to be unpredictable without knowing who is granting those marks. Someone who is heavily in favor of one style over the other may grant higher marks to low quality uses of their favored style than they would to high quality answers in the other style.
The idea of being faster is both personal and situational. If someone is more comfortable using one over the other, they will usually be faster with that style, whichever it is. Some projects seem to do better in one style than they do in the other, even when the person doing the project is proficient in both styles. This is related to the strengths and weakness of each style.
Pseudo code is more free-form, and allows one to concentrate on how to solve the problem or design the algorithm without having to choose the proper symbol to draw, or how to leave room for other branches on the chart. Pseudo code is also closer to the programming statements that will be used, eventually, to implement the algorithms, and can speed up the coding process. Being free-form makes it harder to spot missed checks on conditionals. It is also harder to see the overall pattern of a larger algorithm in pseudo code.
Flowcharts diagram the algorithm in a visual manner that makes the entire algorithm visible. When the logic gets complex, this visual representation enhances the ability to trace all branches and confirm that every conditional has been fully handled. It can also show cases where things are getting to complex, and need to be re-factored. The downside to this visual representation is that the creator frequently needs to interrupt their work on the algorithm to make adjustments to the chart, or to redraw sections that no longer fit on the page/screen they are using. These points are even greater detractors when the flowcharts are created on paper rather than in a program designed for flowcharts.
The apparent speed gains from pseudo code's closeness to the final language can be offset by the error checking, and corrections needed, but not spotting logic error in the planning, which is one of the strengths of a flowchart. In addition, the larger picture view provided by the flowchart that can lead to re-factoring, can lead to more compact and efficient code, which is a gain every time the program is executed, even if it took longer to code the first time.
Ideally the students should be taught each method, using exercises that are both a good fit and a bad fit for that method. After leaning the two methods they should have exercises that help them learn how to select the proper one for a given situation. While it may not be appropriate for the classroom, often a programmer on a larger project will use both methods: the flowchart to see the whole picture, and plan the program's overall flow, and pseudo code for many of sections seem to be compact or straight forward.
Bottom line is that the best one to choose is the one that gets the job done right the first time. A fast solution, which then needs lots of corrections is not so fast after all, and a pretty picture of the program can still have logic errors if the programmer is not looking at the real problem the correct way.