Why should I keep BuildConfig in ProGuard?

BuildConfig contains a number of useful values that are set at compile time. Specifically these:

boolean DEBUG – if the build is debuggable.
int VERSION_CODE
String VERSION_NAME
String APPLICATION_ID
String BUILD_TYPE – name of the build type, e.g. "release"
String FLAVOR – name of the flavor, e.g. "paidapp"

You can also set your own config values, e.g. different urls for testing and production, and retrieve them from the BuildConfig file instead of maintaining your own Config.java file. This can be done by adding buildConfigFields to your gradle buildTypes like so:

buildTypes {
    debug {
        buildConfigField "boolean", "SOME_VAR", "true"
    }
    release {
        buildConfigField "boolean", "SOME_VAR", "false"
    }
}

So to answer your question, as far as I know you don't have to keep the file, but it's good practice to do so and to use it for your config needs.

As with any other class, you need to -keep the class if you're accessing it indirectly via reflection so ProGuard won't obfuscate it or optimize it away as unused.

Most often the access patterns with BuildConfig are direct without reflection so in those cases it's fine to have ProGuard process your BuildConfig, too.