What is the added advantage of using Bazel over Gradle?

I'm the author of the Bazel support in that repository, and I work on the Bazel Android rules team. farhana has written an amazing answer already, but I just want to add on a few points:

• Bazel is the build system used internally at Google, and that means it's the same build system used to build Google apps like YouTube, Gmail, and Photos.
• Some of these Google apps are huge, and will take Bazel very long to build them locally. Therefore, there's a remote execution feature in Bazel (on top of a remote cache like Gradle has, but more fine-grained IIUC) that allows you to fan out your build actions to a remote farm of executors. Bazel has a static and hermetic dependency graph of actions that is designed to be fully reproducible, with each action having a fully declared set of inputs, outputs, environment variables, command lines, and additional knowledge within Bazel about configuration, toolchains and host/target/execution platform. With this graph, Bazel can safely farm out actions to remote workers, enabling very large degrees of parallelism. I have successfully built the Tensorflow Android app with 500-800 parallel jobs on Google Cloud Remote Build Execution before.
• Automated test discovery. Bazel's static graph also encodes the dependencies between tests, binaries/libraries and data, so making a change in your source files automatically invalidates all tests that depend on them. This tells Bazel to rerun the tests, and skip the cached ones if they do not need to run again. And yes, you can use remote execution with tests too, so you can run hundreds to thousands of tests at the same time.
• Bazel can build many languages: C++, Go, Java, Scala, Rust, and even Haskell. It can also build clients like iOS and Angular/TypeScript/JavaScript. This means that you don't need a separate tool like CMake to build your NDK and C++ code. You can use the same build tool to build both front and backend, and run integration tests together.
• Bazel has a built in command called mobile-install, which allows for fast and iterative development of Android apps. It builds your app, shards out native libs, dexes and resource files, and only pushes changed shards to the device to reduce build and deploy times. Read more about it here.

Is it really good to have TWO build tools for Android?

There are more than just two: Buck & Pants are two other popular build systems for Android. Each build system has its pros and cons, and are designed and implemented to solve a particular set of requirements. For example, Bazel (and its surrounding ecosystem of tools) was born out of Google's gigantic monorepo, so it solves scalability issues really well.

Having the option to try out different approaches, IMO, is a good thing.

Does it mean that Android developer probably need to learn this new build tools in future?

Bazel is open source and has support in Android Studio via the Bazel plugin. If you think it looks interesting, feel free to try it out! We're still in early stages of adapting the Android rules to work in the open source world, so expect some features to be work-in-progress for the time being.