When futures and shared_futures first arrived in C++11, their shared state carried an exception to the usual rule about const functions not incurring data-races:

[futures.state/10] Accesses to the same shared state conflict (1.10)

This is likely the issue that Scott Myers refers to in his book. Yet it is difficult to see how even each thread having its own copy of a shared_future would alleviate this problem without extra synchronisation.

Meanwhile, C++14 changed the exception to read:

[futures.state/11] Access to the result of the same shared state may conflict (1.10). [ Note: this explicitly specifies that the result of the shared state is visible in the objects that reference this state in the sense of data race avoid- ance (17.6.5.9). For example, concurrent accesses through references returned by shared_future::get() (30.6.7) must either use read-only operations or provide additional synchronization. — end note ]

shared_future::wait() doesn't refer to the shared state's result and so should not incur a data-race. Additionally, read-only access to shared_future::get() is explicitly called out as safe. Consequently, if get() internally calls wait() then wait() is also safe. Otherwise, a safe wait() can be trivially implemented by calling get() and ignoring the returned reference.