I have made some search in the internet and it seems the CSRF token mechanism is not just applied to OData, but a generic approach to prevent exposed HTTP resources from CSRF attack, for example the idea is also applied in the good-old ASP MVC application which has nothing to do with OData.
https://issues.oasis-open.org/browse/ODATA-262
In SAP implementation, the CSRF token is generated and maintained in so called “security context” managed by ABAP Netweaver：
First the current session ID is retrieved by function TH_GET_SECURITY_CONTEXT_REF: 04D8A63F901811E9ABAD02000A212071
Then the associated context is retrieved by this session ID via cl_http_security_session_admin=>get_associated_contexts. The token is one part of context.
In this aspect our OData is not stateless, I agree with you. It’s disappointing that we have to explicitly request token in our nodejs/java/ABAP program, however in UI5 aspect, the UI developer needn’t to handle with it manually：
https://openui5.hana.ondemand.com/#/api/sap.ui.model.odata.ODataModel/methods/getSecurityToken
