Why do some compilers generate direct machine code?

Some Intel processors even have hardware level translation layers that take the front level ISA that is exposed to the programmer and translate them further closer to the machine.

That concept is called microprogramming and has been around in theory since Charles Babbage and in implementation since the 1960s. Some processors aren't microprogrammed at all and use hardware to execute the instructions, others are entirely microprogrammed and some take a hybrid approach depending on what instruction is being executed.

Given such power is provided by the ISA/Processor itself...

That power exists in the processor but isn't provided. The API for a processor is its instruction set. The microprogramming, if there is any, is an implementation detail that you're not supposed to know or care about.

... why do compilers generate direct machine code, or is it just a black box and internally it uses assemblers to convert them into direct machine code?

I'm sure there are a few compilers that directly generate object code, but most generate assembly and then assemble it behind the scenes. Assembly is just a human-readable longhand for the corresponding object code that's a lot easier to generate and use for debugging or just understanding what the compiler produces. Odds are very good that if you're writing a compiler for a target, you'll already have a perfectly serviceable assembler (or cross-assembler) that's preferable to use over re-inventing that wheel yourself.

I hear that JVM takes byte code and translate them directly to machine code(exe).Is this true or is my understanding wrong here?

Early versions of the JVM were, essentially, emulators that would examine each bytecode instruction and carry out the operations needed. This is very similar to what microcode does, just implemented in software on a general-purpose computer. Early JVMs were also very slow, which led to the use of things like just-in-time compilation of bytecode to native instructions.

None of this matters, though, because the lingua franca for Java is Java bytecode. This is no different than the instruction set on a real CPU in that you don't care how it's implemented under the covers. There are, in fact, a number of CPUs called "Java processors" that can run Java bytecode directly, a variant of the ARM9 being one of them. Java software won't know or care if it's being run on a Java Processor or JVM.

Compilers may output assembly code, linkable object code, or ready-to-run machine code; I've worked with examples of all three types. Although compilers which output assembly code may be more adaptable to different platforms than those which output object code, outputting assembly code is often slower than outputting machine code, and running a program will require the assembly code undergo further processing steps. It really isn't much harder for a compiler to generate machine code than to generate assembly code; in some cases it may be easier.

As for whether to generate linkable or ready-to-run code, it's often faster and easier for a compiler to produce the latter; the only advantage of producing the former is that building a program will require recompiling only the parts that have changed, and then linking everything, versus having to feed everything through the compiler. If projects will generally be large, and the portion that changes on any given build small, then being able to selectively compile the parts of the code that have changed may be a 'win'. If, however, one is apt to want to rebuild most of the program on each build, producing runnable machine code may be faster than going through an intermediate link stage.

An additional benefit of producing runnable machine code is that a compiler may be able to take advantage of things it knows about the locations of objects in ways that would not be possible when generating relocatable code. For example, if foo and bar are declared in separate modules, a statement foo=bar; would require something like:

    ldr r0,[pc+(_addr_of_bar-*)]
    ldr r1,[pc+(_addr_of_foo-*)]
    ldr r2,[r0]
    str r2,[r1]
 ...somewhere within 2K of the above:
 _addr_of_bar: dw _bar
 _addr_of_foo: dw _foo

If variables foo and bar happen to be at known addresses which are within 4K of each other [e.g. 1600 bytes apart], the code could be simplified to something like:

    ldr r0,[pc+(_addr_of_foo_bar-*)]
    ldr r1,[r0+600]
    str r1,[r0-1000]
 ...somewhere within 2K of the above:
 _addr_of_foo_bar: dw _foo+1000

Such optimizations are only possible if the compiler knows how things are going to be placed.