Fair warning, as you said, we don't really do this anymore - "low level" and "today" contradict each other somewhat. Higher level languages are just too convenient in producing complex actions from less code. Even on embedded/lower level environments we still, at the very least, use C. I'd say C is probably what meets most of your requirements - about as low level as you'll get these days outside of assembly and easy enough to do start doing basic data manipulation quickly if you don't want to dig too deep into the features without too much complexity, having the added bonus of being still somewhat relevant.
Right off the bat, an additional warning to save time/sanity: you've mentioned instruction sets, implying writing in machine language - this wasn't done much anymore even 30-40 years ago. Assembly is almost a 1-to-1 equivalent to it with a minor abstraction layer and a few convenience features. Machine language is both too complicated and specific to the processor/family to be even niche useful these days.
To address your goals/reasons:
(assumed: web bots?) Lower level languages are the opposite of easy. Try different high level languages for creating bots: javascript, python (in a VM). If you're looking to see how they work when all you have is the binary/executable, have a look at disassemblers/decompilers (in a VM). Be prepared to commit to a puzzle - most things aren't designed to be reverse engineered, and some even are designed to thwart the attempt.
Grab/make a golfing language: code golf is a more about the puzzle of the shortest code than producing a working/modern project. Golfing languages are optimized for the purpose of golfing at a higher level than most general high level languages. Assembly/C could work, but the number of bytes it takes to do even some simple things would be prohibitive. Look up "assembly print to console" or even "C print to console" for generic examples, then compare it to an equivalent code golfing language like Jelly or 05AB1E.
We're doing a lot (!) of Arm these days. For the overall goal of learning and becoming more familiar with today's hardware/engineering technologies, I suggest looking at an Arm target - a Raspberry Pi is a convenient/cost effective way to get a quick host going.
It's not going to be easy any way you cut it, but try debugging programs in Linux ddd, a gdb gui. Write some simple programs in C with some breakpoints to see how a lower-ish level language and the compiler represent ideas in assembly/machine language - especially when the optimization flags are changed in the compilation. After that, try some higher level compiled languages - i.e. C++, Rust - and see how different they look under the debugger/disassembly to understand how much complexity a modern compiler handles for us.
If still desired at this point, try your hand at assembly for the experience - "as" is included on the default Pi image as of writing. Even in 8085/MIPS assembly, we're still dealing with the basic building blocks - loads/stores, registers, etc. To produce complexity out of the basics, strong organization/strategy will be required to maintain/break down the long segments of code required - the name "BF" can be appropriate here for programs of sufficient length to be useful: they're a magnitude more complicated than the equivalent high level code would be.
That being said, I'd also suggest doing the same thing on Windows/OS X if you can get a hold of the hardware/tools - modern systems/technologies include them as well.
Keep in mind that lower level languages are usually brought out for hardware specific reasons/optimizations in the rare case that a higher level language isn't cutting it. Often one of the more essential tasks in a project is choosing the tools for the job that yield the correct results, as quickly as possible, using the least resources - lower level languages typically don't fit these goals anymore.
