Processors have instructions to compute the sine, cosine and tangent of floating-point numbers, but not the secant, cosecant or cotangent. So the reason could just be that especially for older languages, the standard library's mathematical functions were just thin wrappers around the processor's capabilities; and newer languages might have just been copying from those languages ever since.

On the other hand, I can think of a concrete performance reason why it's better not to provide these functions in the standard library. In almost all use-cases, you don't want just the secant, cosecant or cotangent, you want it multiplied by some value; these trigonometric functions are defined as ratios of side lengths in triangles, so you can find an unknown side of a triangle by multiplying a known side by the appropriate trigonometric function of a known angle.

For example, you could write code like this:

let hypotenuse = adjacent * sec(theta);

But if sec(theta) is a function which returns 1.0 / cos(theta) then (without compiler optimisations) this code will do an unnecessary multiplication by 1 and also an extra function call. The alternative way of writing it is:

let hypotenuse = adjacent / cos(theta);

For the compiler to optimise the former into the latter, it must inline the sec function, rewrite the expression a * (1.0 / c) as (a * 1.0) / c, and then eliminate the unnecessary multiplication. In reality, even modern compilers don't do this optimisation, because it can change the result slightly, and the compiler can't know that the user doesn't mind the slight difference (or that the latter version is slightly more accurate according to the user's intent).

But even though the version with cos is more efficient and slightly more accurate, many programmers might presume that if sec exists in the standard library then it must be better to use it. Therefore, excluding it from the standard library causes users to write the better version with cos. Exactly the same reasoning applies to cosec and cot.

Older processors had instructions to compute the sine, cosine and tangent of floating-point numbers, but not the secant, cosecant or cotangent. So the reason could just be that especially for older languages, the standard library's mathematical functions were just thin wrappers around the processor's capabilities; and newer languages might have just been copying from those languages ever since.

On the other hand, I can think of a concrete performance reason why it's better not to provide these functions in the standard library. In almost all use-cases, you don't want just the secant, cosecant or cotangent, you want it multiplied by some value; these trigonometric functions are defined as ratios of side lengths in triangles, so you can find an unknown side of a triangle by multiplying a known side by the appropriate trigonometric function of a known angle.

For example, you could write code like this:

let hypotenuse = adjacent * sec(theta);

But if sec(theta) is a function which returns 1.0 / cos(theta) then (without compiler optimisations) this code will do an unnecessary multiplication by 1 and also an extra function call. The alternative way of writing it is:

let hypotenuse = adjacent / cos(theta);

For the compiler to optimise the former into the latter, it must inline the sec function, rewrite the expression a * (1.0 / c) as (a * 1.0) / c, and then eliminate the unnecessary multiplication. In reality, even modern compilers don't do this optimisation, because it can change the result slightly, and the compiler can't know that the user doesn't mind the slight difference (or that the latter version is slightly more accurate according to the user's intent).

But even though the version with cos is more efficient and slightly more accurate, many programmers might presume that if sec exists in the standard library then it must be better to use it. Therefore, excluding it from the standard library causes users to write the better version with cos. Exactly the same reasoning applies to cosec and cot.