ISA opcodes---Where do they come from?

It depends how old the ISA is.

In the early days of hand design, and even more so when CPUs were assembled from discrete logic, the logic design would have come first, and been extensively minimised, and then the ISA bit patterns would have been whatever values were required to make that minimal logic work.

So there may be a particular pattern of control signals that enable some multiplexers to connect the ALU output to the input of the GP register file, a few more control signals that instruct the ALU to add, subtract, AND, OR etc, and a few address bits into the register file. These three groups of signals will form fields within the instruction. Each group will be kept together, and their detailed meaning arises out of the design for that unit (ALU etc) but the groups may be in any order, up until you design the instruction decoder. (the x86 is old enough that you can detect some of this if you look in the right place - it wasn't a totally new design, but drew from the older 8080)

Later ISAs may be "cleaned up" and made more regular and simpler to use, with hardware to translate between them and the actual hardware-level control signals, sometimes via "microcode". These are called "CISC" or "Complex Instruction Set Coding". The x86 "Rep" instruction prefix is a simple example of this - it causes the following instruction to be repeated a number of times, to save having to write a FOR loop.

Later still (in the 1980s) came a movement back to a simpler style of direct encoding (RISC - Reduced Instruction Set Coding) which you can see in the ARM processors. This was driven by the small size of ASICs at the time, and the desire to put 32-bit CPUs on them, hence there was no spare capacity for complex instruction set decoders, to get the complete CPU down to about 20,000 gates. (There was also a temporary performance boost, because people hadn't developed techniques to make CISC decoders fast yet - that came about 1995 with the Pentium Pro)

And nowadays it doesn't matter - CPUs read several instructions at once, and devote millions of transistors to decoding them, re-ordering them, and executing as many as possible at once, to speed up programs that may have been written for the oldest style of ISA.

If you group similar instructions together, patterns will emerge. This is very obvious in ARM, where the ISA manual actually shows you which bit of an instruction word correspond to function, register choice, etc. But it can also be inferred for X86.

Ultimately the "function" part of opcodes go into some binary-to-onehot decoder that actually activates a particular function or sequence of pipelined operations. They are not usually related to the contents of any state machine, unless we're considering variable-length instructions which require a state machine to decode.

Someone at some point sat down and defined them.

A good ISA will make the decoder as simple as possible.

For example with an ALU instruction you could let some bits of the opcode be sent directly into the control lines of the ALU.