Why put protocol implementation in an extension in Swift?

I am not a Swift expert, and I don't know why Apple used this style in their tutorials. They could probably have written it in the simpler way you suggested. Maybe they left it this way to demonstrate the syntax and ideas behind Swift extensions - we had to ask the author directly for getting this to know.

Nevertheless I think I can explain what extension methods are and what their main usage is: you can add functionality to existing structs, classes, enumerations and protocols even when you don't own them, when you cannot (or do not want to) change their source code, especially when you don't have access to the source code. The concept of extension methods from C# - which I know well - is very similar, you find a good explanation in this article.

A specialized use case is to add a specific extension method to a general purpose class for a restricted context. For example, in the Score keeper example, Player might be a general purpose struct for players, in a general library which may also be used out of the Score keeper context. Still,in the context of this app, apparently it makes sense to identify equality of two player objects by their name and their score. Without the app's context, this looks quite surprising and probably not suitable as a general definition of equality for players outside of this app.

Now, if one wants to prevent this specific kind of equality test to leak into the general Player struct (and so into other contexts outside of this app), one may use an extension inside the app's code to implement Equality, clearly separated from the Player struct code.

Still, in the tutorial, all the code (the struct definition as well as the extension code) is in one source code file, and the author had probably access to all the code, so in that contrived example, there is no necessity to use the extension syntax. But hey, this is a tutorial, don't overthink it - real world code might be more complex, with extra layers and more than one app and library involved. The tutorials are probably designed with the intention to prepare readers for the real world.

Your example adds conformance to a protocol via extension. It is also called retroactive conformance or retroactive modeling. It can be done whether you own the implementation of the struct, or just use a struct implemented by someone else.

It's a kind of ad-hoc adapter when conformance to the protocol is not a core feature of your new type. In plain words: the design of a player might not need it to be Equatable in general, but Equatable could be useful in some situations( Example).

This idiom is also popular as it allows to visualise separation of concerns: each additional protocol conformances is shown closely together with the corresponding implementation. Here, the link of == to Equatable is obvious. But imagine using a struct with a more complex protocol, such as Encoder: with conformance via an extension, you'd visualise the corresponding 5 required features very easily.

It's usually a good idea to keep classes small. In Swift, where you have classes and extensions, it is a good idea to keep both classes and extensions small. In this case, it means that instead of a class with the Equatable code, you have a class, and an extension.

This is especially a good idea for something like "Equatable", where many, many classes support the "Equatable" protocol, and you can put all the implementions into separate extensions, and group them all together. Usually you are not concerned at all about the implementation of "==", because it is quite obvious for each class what it should do and how it is implemented, so it doesn't distract you from the important bits.