Your last paragraph describes my typical use case really well!
I agree 100% with Knoobie’s opinion.
My point is with Vaadin Flow, everything I do is on the server, and Flow takes care of remote communication.
With Hilla I have to care what is sent over the wire. That means I will always use a Controller/Endpoint/BrowserCallable with DTOs to reduce the data (an also make sure that no data like passwords) sent/received. I would never annotate a Service with BrowserCallable! I would even add ArchUnitTests to prevent from doing that.
That’s why I’m perfectly fine with Endpoint because this indicates that it’s an API.
This is how I see a Vaadin/Hilla architecture
Btw. that’s also the reason why I prefer Vaadin over Hilla as it makes me more productive
There is also the religious debate on whether the service layer API should be based on entities or DTOs 
I would say that “endpoint” is just as much associated with how data is sent (e.g. POST vs GET) as with what data is sent (e.g. which properties to include). It’s this association with how that we want to avoid with the new naming. The idea is basically that you can make anything you want callable from the browser and then it’s up to you where you want to apply it.
Those who are in the camp that thinks that Service should deal with DTOs can put the annotation on their services. Those in the entity camp will in many cases end up with a separate layer only for converting to DTOs. We haven’t yet made up our minds on which side we want to take in our documentation.
I use Services in the meaning of DDD
So it deals with Entities
BUT as you can see in my diagram I use Repositories directly.
I also NEVER use mappers like MapStruct or ObjectMapper. I always create my DTOs directly in the Repository Layer
But I understand that there are now two “styles” when using Hilla:
- Build an RCP API, and Hilla will do everything regarding communication. In that case, the name Endpoint makes sense
- Use a service (not a DDD service but a service like they use the name in, for example, Angular) directly in your client application
Style 2 will blur the line between client and server
From a Spring Boot and DDD point of view, I dislike the idea of calling the class with the BrowserCallable annotation “Service” (service anyway has multiple meanings). That’s my main problem with 2.
I’m not for a religious debate, but for an security obstacle to happen 
the more people are directly using their entities in the frontend world, the higher the chance for leaks or unexpected exposure of attributes not meant for the browser. I see the appeal for simple demos, but in real applications that leads to desaster to happen
Any idea on alternative names if we rule out “endpoint” and “service”?
HillaEndpoint 
or TypeScriptExposed / FrontendExposed … but naming is really hard
Or we go back to square one and call it Connect