It’s a bit more complex than that.
The UI process (the “shell” of the web browser) is a regular BApplication with BWindow and all the usual things. As a result, it cannot both wait on BMessages and sockets in the same thread. So even if we were to use sockets, we would need to run them in a separate thread.
And it’s not like we are doing some crazy hacks to WebKit to put BMessages in it. That’s how WebKit is meant to be used. They use a GLib event loop for the GTK port, but a completely different system for the Mac and Windows ports of it. And the Qt port uses a QApplication event loop. And we can very well provide an implementation of their IPC using BMessages (in fact a large part of the work is already done to encode/decode data to BMessages in the existing port, the only missing part is setting up the BMessengers between different process)
This is the reason we decided to use WebKit for the system browser: it really allows us to provide something that integrates with the native APIs (of course, because that’s also how Apple uses it), and does not run on top of a custom “platform abstraction” that we would have trouble using in a standard application.
What Blink does is fine when your goal is just to build a web browser. But it isn’t as much suitable when you want a generic framework for embedding web views into native applications (for example, HTML view in a mail client or an RSS reader).