I've been reading the source code of both FreeRTOS and CoOS.

In FreeRTOS (the port I found first in Google), the xSemaphoreGiveFromISR() function calls to xQueueGenericSendFromISR(), and this function had this comment:

/* Similar to xQueueGenericSend, except we don't block if there is no room
    in the queue.  Also we don't directly wake a task that was blocked on a
    queue read, instead we return a flag to say whether a context switch is
    required or not (i.e. has a task with a higher priority than us been woken
    by this post). */

As for CoOS, the function isr_PostSem called from an ISR just enqueues a request to the so called "Service request queue", using the function InsertInSRQ. I have no idea about what this queue is, probably is some system task to offload work from ISRs and thus let interrupts complete quickly.

As for mbed, which only has 1 version of the method, it is based on CMSIS RTOS, and there's a call to the function osSemaphoreRelease(). There's a comment about this and similar functions:

The following CMSIS-RTOS functions can be called from threads and interrupt service routines (ISR):
  - osSignalSet
  - osSemaphoreRelease
  - osPoolAlloc, osPoolCAlloc, osPoolFree
  - osMessagePut, osMessageGet
  - osMailAlloc, osMailCAlloc, osMailGet, osMailPut, osMailFree

Functions that cannot be called from an ISR are verifying the interrupt status and return in case that they are called from an ISR context the status code osErrorISR. In some implementations this condition might be caught using the HARD FAULT vector.

So it seems to be just kernel design, some designers chose to have separate functions and let the programmer make the distinction, and some others prefered to have just one method and internally check if the call was made from an ISR.

I've been reading the source code of both FreeRTOS and CoOS.

In FreeRTOS (the port I found first in Google), the xSemaphoreGiveFromISR() function calls to xQueueGenericSendFromISR(), and this function had this comment:

/* Similar to xQueueGenericSend, except we don't block if there is no room
    in the queue.  Also we don't directly wake a task that was blocked on a
    queue read, instead we return a flag to say whether a context switch is
    required or not (i.e. has a task with a higher priority than us been woken
    by this post). */

As for CoOS, the function isr_PostSem called from an ISR just enqueues a request to the so called "Service request queue", using the function InsertInSRQ. I have no idea about what this queue is, probably is some system task to offload work from ISRs and thus let interrupts complete quickly.

As for mbed, which only has 1 version of the method, it is based on CMSIS RTOS, and there's a call to the function osSemaphoreRelease(). There's a comment about this and similar functions:

The following CMSIS-RTOS functions can be called from threads and interrupt 
service routines (ISR):
  - osSignalSet
  - osSemaphoreRelease
  - osPoolAlloc, osPoolCAlloc, osPoolFree
  - osMessagePut, osMessageGet
  - osMailAlloc, osMailCAlloc, osMailGet, osMailPut, osMailFree

Functions that cannot be called from an ISR are verifying the interrupt 
status and return in case that they are called from an ISR context the status 
code osErrorISR. In some implementations this condition might be caught using 
the HARD FAULT vector.

So it seems to be just kernel design, some designers chose to have separate functions and let the programmer make the distinction, and some others prefered to have just one method and internally check if the call was made from an ISR.