Ah, yes, I thought that might be a bit controversial. From practical experience building HAL APIs the _embedded pattern causes a lot of confusion. First of all, within an organisation you need to decide pretty firmly whether you're going to allow people to embed partial presentations or only whole representations. If you do partials then that's quite hard to document well and can cause funny bugs in conjunction with the practical reality of not using schemas - how do you know if the full representation has the "foo" property set by looking at the embedded one? You don't.
If then decide to embed full representations, what exactly have you gained? The data to build the representation has to be fetched and the code to build it executed. You may save the users an extra request, but then some other users will complain because your response is loaded down with resources _they_ don't want.
Further, when you embed a resource, you lose all that nice HTTP caching information in the headers. Worse, you have to share that information across the primary and embedded resources.
So my strong personal preference in any real HAL API will always be to ignore the _embedded pattern completely, let clients request what they want, and indeed really the API user should have all of that hidden from them by the HAL client. It really makes no sense to have two different methods for getting the same resource.
Of course if you take a different view on the issue of partial representations then my entire argument is moot, but literally days of my life spent trying to get multiple teams to agree on what to embed or not have left me scarred!