For most purposes, using a deque is almost as fast as a vector according to some of my submissions.

There are only two issues that I know of that anything using a deque can face:

1. When you need to rely on the cache a lot: even though allocations are done in blocks to avoid this problem, in some extreme cases it might lead to some noticeable slowdown (about 10-30%). This might be an issue with vectorization in the future, but usual block sizes are large enough to avoid this issue to a large extent. Usually online judges don't have very tight limits that are able to differentiate between vector and deques in this scenario.
2. Allocating too many deques: If you do something like vector<deque<int>> a((int)1e6);, it is going to MLE (and if not MLE, TLE) because a deque allocates memory in chunks, and that chunk tends to be large. For example, using GCC on codeforces, it is 512 bytes, and it is quite bad to allocate a vector of $$$10^6$$$ empty deques in this case.

I think the second part is the reason behind the comment that deques are slow, but feel free to correct me if this issue showed up in some other context.

Some python people avoid using deque for their BFS by doing something like:

        q = [src]
        seen = [0] * N
        seen[src] = 1
        for u in q:
            for v in graph[u]:
                if not seen[v]:
                    q.append(v)
                    seen[v] = 1

which translates to the following in c++:

        vector<int> q = {src};
        vector<int> seen(N, 0);
        seen[src] = 1;
        for (int i = 0; i < q.size(); i++) {
            int u = q[i];
            for (int v : graph[u]) {
                if (!seen[v]) {
                    q.push_back(v);
                    seen[v] = 1;
                }
            }
        }

Is it possible to declare a,b under while?

I agree with this, and it is definitely not a hot take in my opinion. In fact, in some competitive scenarios I've observed that using std::array helps with vectorization as well and std::pair and std::tuple have surprising inherent overheads compared to a toned down implementation like template <class T, class U> struct Pair { T first; U second; }; (so much so that some software companies ban their use in their codebases). I would recommend watching this for a good introduction to why this is the case. EDIT: just watched it again, and it seems an important reason in the competitive programming context wasn't covered. std::pair and std::tuple are not forced to be trivial types even if their members are, so this adds some non-zero overhead sometimes. Similarly, sometimes compilers aren't able to reason through all the abstraction that is provided by the suboptimal std::pair and std::tuple implementations, so that factors in sometimes too.

However, I have seen way too many people spamming std::pair and std::tuple everywhere, and it is quite annoying to look at (even more so to write) push_back(make_pair(...)) all the time. The main idea is that if you use std::tuple, you should at least make your code not-so-ugly.

There are still examples where you might need std::tuple: one reason to not completely abandon it in favor of simple structs is that you can't use ranges::elements_view with structs having different types, because std::get is defined only for them (and std::array and std::pair). Perhaps this can be fixed with better "accessing" functionality for structs, but I don't see how to do this.

How to use std::array if you want elements to be not of the same type?

How do you implement a scanline then? You usually have two types of events (something started and something ended) and you need to sort events firstly by the $$$x$$$ coordinate and then by the type. A tuple of $$$x$$$, type and parameters (usually tuple<int, bool, int>) does perfectly fine from my perspective. Do you define a structure with a custom comparator here as well?

How do you code Dijkstra?

You should have it if your compiler is up-to-date. Make sure you don't have compiler arguments setting you to an older version (use -stdc++=20 on GCC/Clang, and /std:c++20 or /std:c++latest on MSVC).

That's true (and it makes more sense too)! However I almost always use end(a)[-1] instead of rbegin(a)[0] because:

1. It keeps things consistent across languages — Python and C++.
2. It has fewer characters.
3. I avoid using reverse iterators too much, since sometimes you can mess up by using ++ instead of -- and vice versa if you mix iterators.

For the last element please use .back(), .front() also exist for accessing the first element but [0] is shorter anyway.

No

Why? I think it's just a double-ended linked list

Check this.