The reason that you find few implementations is most likely because CoAP is a relatively young protocol. It was first proposed in 2010, and the current version dates from 2014: RFC 7252.
For application level protocols the popular alternatives are HTTP, which is heavy for constrained devices, and MQTT, which requires a broker device and runs on TCP. They ...
No, CoAP is an application layer protocol it's not dependent
Basically that's the beauty behind the OSI layers. If correctly implemented you can mostly stack them however you want. As with every thing that starts with if correctly implemented that's mostly academic and some protocols fit better together with others than others do. More or less the only ...
I'm not sure, if this is a answer or should be a comment, but though I don't have enough reputation to comment ...
End of last year there have been some news about the (mis?) usage of CoAP.
Message in the IETF core-mailing-list
Article in zdnet
The article mentions:
"Rand suggests the reason for this explosion is CoAP's use as part of QLC Chain (formerly ...
CoAP and MQTT have both equal RAM usage, measured in 10kbits .
Difference is in cpu and network usage: 
Every client supports TCP and holds a connection open to the broker.
So, CoAP has fewer foot print and according to the whole use case (small data once in a while) it seems to be your best choice.
As you referred, CoAP uses UDP. It does not ...
There are no standards only RFCs for CoAP; all of them are accessible on the web:
RFC 7228 - Terminology for Constrained-Node Networks, May 2014
RFC 7252 - The Constrained Application Protocol (CoAP), June 2014
In addition to Achim's comment (and with the same uncertainty as to whether that'd be an answer or a comment), you may want to consider the following:
A single installation rolling out, MQTT, would show up as a single (or a small number of) broker(s), while CoAP uses direct connections and thus, usually in some setups, has each node discoverable ...
You would need a 'gateway' that can translate from CoAP to MQTT (and vice versa). Various examples exist, such as:
emq-coap which allows CoAP clients to communicate with an instance of the EMQ MQTT broker (a usage example is given in the README)
Eclipse Ponte, which bridges HTTP, MQTT and CoAP. An example is given that you can send a message to mqtt://<...
The protocols you mentioned are application layer protocols and they run over TCP or UPD, you can not use an application layer without IP.
But you can use an implementation of MQTT for Sensors called MQTT-SN it works for M2M or D2D.
You can check for the protocol specifications here
also here is the Eclipse project for MQTT-SN
One of the answers above says that CoAP uses UDP and hence does not guarantee data delivery. This is not completely true. CoAP has a non-confirmed mode and a confirmed mode of sending messages.
In confirmed mode, CoAP will do retries to try to ensure delivery. You can tune the timeout and retry attempt count.
The non-confirmed mode does not retry and is the '...
I don't think, there is a easy answer, nor a fair one.
One aspect of scaling maybe the distinguish between "hot" and "cold" data (say "hot" you must always fetch from the single fresh source (hardly scaling), while "cold" could be duplicated and deployed and may not be fresh (easier scaling)).
REST (request/response) I would consider to support also "cold" ...
Californium is designed to process many request simultaneously. Therefore it uses callbacks (CoapResource).
May be I missunderstood your intention of the question. For me "all in main" sounds as an approach with a "blocking functions waiting for incoming requests and returning them". That is not intended with californium.