[yalue]

You may be interested to know that there has recently been a notable movement in systems security research to push for an "execute-only" permission, that makes executable data unreadable in addition to unwriteable. This has come in response to certain attacks (i.e. http://www.ieee-security.org/TC/SP2013/papers/4977a574.pdf) that use scripting languages (such as JS or Flash's actionscript) to read all of memory at exploit time and use this knowledge to craft a payload that bypasses ASLR.

So, works such as http://www.ics.uci.edu/~sjcrane/papers/sjcrane15_readactor.p... (and several others) are attempting to come up with systems that can prevent this type of attack by preventing executable memory from being read in the first place. This is made difficult not only by the fact that even if processors could support such permissions (many generally can't in any efficient fashion), but also due to the fact that many compilers frequently mix together executable code and static data, such as strings. The second paper I linked is about instrumenting LLVM to ensure that it always outputs readable data and code in separate sections.

Having been involved in such research myself, I can confidently respond to the parent's question too by saying that, if anything, a majority of modern compilers freely mix code and data. In addition, there is often data that is directly related to code, such as tables of addresses used in a switch statement, but is never intended to be directly executed. Even if it would work just fine to place such tables in a read-only section, it may make logical sense to the compiler authors to place it in the vicinity of where it is used (that is, in the executable data section).