I have cloned the https://github.com/vaadin/skeleton-starter-flow project, ran mvn jetty:run on it and modified the MainView's constructor to look like this:
public MainView() {
ExampleTemplate template = new ExampleTemplate();
final TextField foo = new TextField("Foo");
Button button = new Button("Click me", event -> template.setValue("Clicked! " + foo.getValue()));
add(button, template, foo);
}
When I click the "Click me" button, I want the text I've entered into the "Foo" field to appear along the "Clicked! " string. Instead, it comes up empty.
It's Flow 1.0.0.alpha3

In fact, you can use this way to achieve your goal:
foo.addValueChangeListener(event -> event.getValue());
button.addClickListener(event -> {
template.setValue("Clicked! " + foo.getValue());
});
If i recall correctly, in your way, the foo.getValue() is getting the initial value from the textField which is empty and it doesn't fire an event until you add a listener to it.. :)

Ah, so the value is not transferred to the server side until the value change listener is added :) that's why it worked in the beverage demo - it uses binder which internally sets the value change listener.
Anyways, I believe that the value change listener should not be required in order for the value to be transferred from client to server.
yes, the usage maybe look not very straightforward as using getValue() directly, but change listener is used to sync the value from the client to server.
We should be making the TextField send the value to the server always on e.g. blur event when there has been a change, even if there is no ValueChangeListener applied.
Without that, we will confuse some users (like now), and that is always a bad thing. This is pretty similar what we had in FW 6 & 7 with the immediate property.
Issue moved to vaadin/vaadin-text-field-flow #4 via ZenHub
Most helpful comment
We should be making the
TextFieldsend the value to the server always on e.g.blurevent when there has been a change, even if there is noValueChangeListenerapplied.Without that, we will confuse some users (like now), and that is always a bad thing. This is pretty similar what we had in FW 6 & 7 with the
immediateproperty.