In a practical industrial application, MQTT is not an alternative to OPC-UA. The original goal of OPC, back in the '90s, was to provide a standard communication mechanism and data model that would provide interoperability among clients and servers that implemented the specification. OPC-UA expands and generalizes the data model and the communication without giving up on that core goal. In order to do this, the standard must specify things like the format of a time stamp, the encoding of data types, historical values, alarms, etc.
MQTT is a message transport layer that does not provide interoperability by design. It does not stipulate the format of the payload, does not specify how one transmits a particular data type, timestamp, value, hierarchy, or anything else that would allow an application to understand the data being transmitted. You can create a valid MQTT server that emits XML, JSON, or custom formatted data that is plain-text, encrypted, base-64 encoded, or anything else you like. The only way a client application can interact with your server is by knowing in advance what data format the server will produce and accept.
OPC-UA has recently introduced a publish/subscribe mechanism to improve bandwidth utilization, reducing a communication bandwidth advantage that MQTT currently offers. At the same time, the MQTT specification will need to grow to specify data formats in order to promote interoperability. Expect to see a convergence of functionality between MQTT and OPC-UA, mostly MQTT growing to meet OPC-UA.
MQTT is a much simpler implementation at the moment, which holds advantages for embedded and resource-constrained systems. The addition of a data modeling specification would act to reduce this advantage.
The bottom line is that OPC-UA is for interoperability and MQTT is for simple custom communication. MQTT needs to grow before it can be an alternative to OPC-UA.
