But the compiler/linker is smarter than that.
Once again, your expectations are wrong.
What is this 85E7 as has been found in the hex file of post #15? Is this instruction/opcode not containing opcode (8E) and operand (75)? An example using assembly:
.cseg
.org $0000
000000 c03f RESET: rjmp L1
.org 0x0040
000040 e203 L1: ldi r16, 0x23 ; our instruction of interest
000041 940c 0041 L2: jmp L2 ;
What is this 85E7
It would be really a good thing for you to carefully read the posts, as they explain the problem you are having with your false expectations, and your difficulty understanding what the compiler is doing.
85E7 is explained in post #14. But for complete clarity, the "5" in "85" is the lower nibble of the hex constant "75".
I'll leave it to you to figure out where the "7" is hiding.
You are saying so; because, I have asked for 75. I know that operand does not come like that in AVR architecture; it comes following instruction of post #14 being intermixed with opcode.
Sometimes wishes come true 
I want to tell how much I like Wokwi, so I was hoping that you would ask how I got the assembly code.
In Wokwi, with a new project for the Uno, copy paste your code into it, then right-click on the sketch and then "Command Pallette" (or pressing 'F1' would also show the menu). Search for "assembly" and select "View Compiled Assembly Code Listing". A new tab pops up "sketch.lst" with the assembly 
There is also a "Download Compiled Firmware" to save the HEX file to "firmware.hex" 
(Perhaps the simulation has to be started now and then to compile it, I'm not sure)
In the Arduino IDE, I can use the menu: Sketch / Export Compiled Binary
It is stored in a sub-folder below my project, in the folder "arduino.avr.uno".
I checked both Wokwi and the Arduino IDE 2.0, as explained above.
Get 0x75 as data
You want 0x75 ? An array of a single byte is still optimized away. So create an array that is large enough to actually become an array of data in memory.
byte myArray[] = { 0x75, 0x75, 0x75, 0x75, 0x75, 0x75, 0x75, 0x75, 0x75};
Then write a sketch that uses the data, so the compiler will use the data and not throw it away.
The data for variables is often at the end of the HEX file, easy to spot.
...
:0A05F000F491E02D0994F894FFCF78
:1005FA0000000000BE003F015F000B0190006E008A
:0E060A0082007575757575757575750D0A002C
:00000001FF
Can I expect answer to Question-4 of my post #15?
I'm only 99% 30% sure 
The Arduino Uno has already a bootloader in its Flash memory to upload code via the serial port. The computer uses avrdude to upload data and avrdude communicates with the bootloader. After power up or a reset, the bootloader is started first and the bootloader can decide to jump to the sketch.
When using a programmer (I use UsbAsp) and the option "Upload Using Programmer", the Flash is rewritten with the code of the sketch and the bootloader is removed.
The Arduino IDE has the option "Burn Bootlader" to restore the bootloader. After that the sketch can be uploaded via the serial port using the bootloader.
The "with_bootloader" seems to be the sketch plus the bootloader. That makes it possible to use a programmer and use the serial port after that without the need for "Burn Bootloader".
I think that the reset vector works together with the fuse for the boot segment.
Standard.hex is what is normally uploaded.
Turn on “verbose” for upload in your preferences, and you can watch in gory detail.
The reason you saw code matching your expectations when using microchip studio is that it defaults to “no optimization” (which you should alway change!)
Then --
1. To get a copy of the MCU of the Arduino UNO Board, the with_bootloader.standard.hex file is fused into the flash memory of an external ATmega328P MCU whose BOOTSZ1, BOOTSZ0, BOOTRST fuse bits must match with that of the MCU of the UNO Board. This is to be done with the help of a commercial ROM Programmer. Is it correct?
2. When RESET Button of the UNO Board is pressed and released, the control goes at location 0x3FF0 and at the end-of-uploading (or if no uploading is requested), the control goes to location 0x0000 and then control goes to a location1 in the Application Section and then (after executing some utility codes) the control goes at the beginning address (location2) of the user program in the Application Section of flash. Is it correct?
3. Any idea about the numerical value for the address of location1 (mentioned in Section-2)?
4. Is the beginning address of the user program (mentioned in Section-2) in the Application Section always a fixed location? Any idea about the numerical value of this location (location2 mentioned in Section-2)?
Great feature ! Is Wokwi using the same compiler as Arduino IDE 2.x ?
I also see a "Create a custom C chip (beta)" menu entry. For some reason, it added a "I2C Counter Breakout" chip on the layout. That may be a great solution to create missing chips ('138 or '154 demux...)
I read a few months ago that Wokwi is using the 1.8.x version. Wokwi has to use the command line version of Arduino. The build environments are listed somewhere (but I forgot where, this is not it?).
So many users were requesting components, that it evolved into custom chips: https://docs.wokwi.com/chips-api/getting-started
There is no "separation" of the "application section utility codes", and the user program - they are compiled and linked together into a single binary. Both start addresses are not fixed, and can vary depending on the order of functions in your source code, whether and how much you have used PROGMEM, and etc. They could be anywhere in the 32k of code space available,
Symbolically, avr-gcc usually starts at __ctors_end (which does C++ environment initialization), that eventually goes to main() (C and C++ program start address, which will do Arduino environment initialization), and that calls the well-known setup() and loop()
1. To get a copy of the MCU of the Arduino UNO Board, the with_bootloader.standard.hex file is fused into the flash memory of an external ATmega328P MCU whose BOOTSZ1, BOOTSZ0, BOOTRST fuse bits must match with that of the MCU of the UNO Board. This is to be done with the help of a commercial ROM Programmer. Is it correct?
An Arduino App for the classic AVRs does not need to include the bootloader to function correctly. You can copy just the application without bootloader, and it will work fine.
This is not true of ARM and perhaps the newer MegaAVR chips.
If interrupts are not used at all, then the sketch may start even from word-location 0x0002 of the flash. Is it correct?
If interrupts are not used, your sketch could theoretically start at 0x0.
In an AVR, the interrupt "vectors", including the "start" vectors, are actually normal code locations that typically contain RJMP or JMP instructions, but they don't NEED to be those.
The optiboot bootloader, for example, completely omits the vector table and starts at 0 (relative to the bootloader flash in general. It's absolute location will be at some location determined by the fuses.)
And people have been known to write their entire ISR at the vector location - you can fit an SBI + RETI in the 4 bytes occupied by a normal JMP instruction, and more if you're not using the immediately following vector. This can save quite a few cycles compared to the normal ISR entry. (well, "several cycles." - in the SBI+RETI case, you'd be setting the output pin at least 3 cycles sooner.)
(Note that this is NOT the case on several other popular CPU architectures. In ARM Cortex-M, for example, a vector is JUST the address of the ISR.)
