Because:

• you overwrite existing implementations (like in your example)
• that implementations influence the global behavior (no encapsulation)
• modified behavior can harm 3rd party modules behavior
• you can generate instability and vulnerabilities

But it is OK to use polyfills (and add-ons) like that:

if (!('entries' in Object)) {
  Object.defineProperty(Object, 'entries', {
    value: function(obj) {
      return Object.keys(obj).map(function(key) {return [key, obj[key]]})
    }
  })
}

PS: Sorry, entries is not defined on Object.prototype, but you know what I mean.

It's not considered bad per-se. When working on your personal app or website, you can do anything you want. But here are a few situations where you might want to reconsider:

• When working in a team or open-source, everyone should know the base functionality of JS, available classes and functions. Everything should be documented. By modifying base objects, you add yet another thing to watch out for which has to be documented, learned and understood by everyone.
• When creating a library, what will happen if your library is used in a context with a different library, which adds the same method to the same base object?
• What happens, if ES2020 standardizes String.prototype.repeat() (actually, it already exists)? You will have to change your code, because it is not forward compatible and you have no control over the browser version used to view your site

Instead of extending the base object prototype like that, I would recommend writing a wrapper, or, even better, a Mixin(composable objects):

const Repeatable = (superclass) => class extends superclass {
  repeat (times) {
    return new Array(times + 1).join(this);
  }
};

class MyString extends Repeatable(String) {
  constructor(str) {
    super(str);
  }
};

var str = new MyString('Hellow!');
console.log(str.repeat(3));