Vindicar

Потому что под капотом большинства оконных фреймворков крутится вечный цикл вида "получить оконное сообщение - определить событие - вызвать обработчик события". И следующее оконное сообщение не будет обработано, пока обработчик события не завершится. Как следствие, длительный код в обработчике "подвешивает" окно программы.
Быстрое и грязное решение - дёргать метод update_idletasks() (погугли про него). Он позволит выполнить перерисовку компонентов GUI, не выходя из обработчика события.
Чуть менее грязное - разбить выполняемую работу на маленькие блоки, выполнять блок, затем планировать выполнение следующего блока через метод after(). Тогда в промежутке между вызовом after() и фактическим выполнением кода у GUI будет время обработать поступающие сообщения. Но не всегда это возможно, да и о конкуррентном запуске надо думать (что если юзер кликнет кнопку дважды, а не однажды?)
Ещё менее грязное - вынести длительный код в отдельный поток, научить поток оповещать о своём состоянии (например, менять содержимое переменной), а через after() реализовывать только опрос этой переменной и обновление GUI. Но переменную надо будет защищать мьютексом, чтобы не словить конфликт при одновременном обращении двух потоков.

1. Для одного элемента можно использовать только один менеджер геометрии. Если ты положил кнопку на форму через place(), не делай ей pack().
2. В рамках одного контейнера можно использовать только один менеджер геометрии. Если ты положил один элемент на панель/в окно через place()/pack()/grid(), другие элементы, положенные непосредственно в ту же панель/окно, должны использовать тот же самый менеджер.

Вместо цикла и win.update() научись использовать win.after().

int(number.get())

Питоновский модуль для sqlite этого не умеет, хотя sqlite сама по себе предоставляет update_hook. См stackoverflow.
Более простое решение - периодически опрашивать сервер, но это может быть напряжно.

Но с учетом твоего другого вопроса, PostgreSQL реализует синтаксис LISTEN/NOTIFY. Есть модули для питона, которые позволяют этим пользоваться. Периодический опрос всё ещё потребуется, но он будет потреблять куда меньше ресурсов, чем SELECT.

fan_gpu_info.after(1000, fan_gpu_info)
Может, имелось ввиду это?
fan_gpu_info.after(1000, fans_gpu)

Есть два подхода. Один основан на лямбдах:

for i in range(2):
    buttonFrame_update=Button(frame,text="Добавить", command= lambda arg=i: update_main_db(arg))

Приём с аргументом лямбды необходим, чтобы сохранить текущее значение i - иначе в момент вызова лямбды она прочитает последнее значение i, а оно будет указывать на последнюю строку.

Второй способ, которя я бы выбрал - написать свой виджет - строку таблицы. Тогда обработчик нажатия на кнопку сможет брать данные из экземплярной переменной.

class MyTableRow(Frame):
    def __init__(self, master, *args, **kwargs):
        super().__init__(master, *args, **kwargs)
        self.widgets = []
        for i in range(3):
            widget = Entry(frame)
            widget.pack(side="left")
            self.widgets.append(widget)
        self.update_btn = Button(self, text = "Добавить", command = self.update_clicked)
        self.update_btn.pack(side="right")
        self.delete_btn = Button(self, text = "Удалить", command = self.delete_clicked)
        self.delete_btn.pack(side="right")
  
    def update_clicked(self):
        print(self.widgets[0].get())
    
    def delete_clicked(self):
        print("whatever")


for i in range(2):
    item = MyTableRow(doth, borderwidth=2, relief="groove")
    frames.append(item)
    item.pack(side="top", fill="x")

Всё что мне приходит в голову - перебрать все виджеты и найти те, чей прямоугольник содержит искомую точку.
winfo_x()/winfo_y() - позиция виджета относительно родительского виджета.
winfo_rootx()/winfo_rooty() - если не путаю, позиция виджета относительно начала экрана.
winfo_width()/winfo_height() - текущий размер виджета
winfo_children() - список дочерних виджетов для данного виджета.

Но зачем тебе это понадобилось? Может, есть способ попроще?